Lessons Learnt in Transformational BPO (Part 2)
This is the second article in a three-part series. To read the first article, click here…
Now to the key lessons learned. I have grouped them by the usual phases of a transformational BPO programme – Design, FitGap, Implementation, Testing and Operations. Most of the lessons are in the first two phases, because this is where transformational BPO differs most from other types of outsourcing.
The Design phase
The design of the new operating model can be undertaken unilaterally by a supplier and made available to the market on a “plug and play” (sometimes called “platform”) basis, or it can be performed in a bespoke manner for a specific client. Large client-organisations have tended to take the latter approach and this is the scenario I focus on in this article. A new operating model is designed centrally and implemented in a standardised form across the various different business or geographical units of the client’s organisation.
The key lessons:
• Anticipate a reasonable amount of local variation. There is natural tension between the desire for a completely standard global model and the need to reflect local specificities. The former objective should of course win out on the whole but there will always be circumstances where features of the local environment cannot be changed to accommodate the global model – for example because of legal constraints. An 80/20 ratio is probably a good rule of thumb for the global/local balance. As long as any proposed local variations are subjected to proper scrutiny in the FitGap phase (see below), these matters can be worked through in a controlled fashion. However, I have seen some global Design teams adopt and espouse the mind-set that no local variation is going to be tolerated. This is just macho and silly – a 100/0 ratio is not feasible and this will become apparent at the FitGap stage. Perhaps the global team is attempting to grab some high ground before an expected battle with the business units, perhaps it has been working in too much isolation (or, indeed, an ivory tower). Whatever the reason, the adoption of such attitudes results in the design losing credibility, “stand-offs” occurring between the local and global communities and even clandestine local workarounds being adopted down the line.
• Don’t build your operating model from scratch. Just as an 80/20 rule is a good starting point on the global v local question within an organisation as described above, so too it may be for the question of how similar one organisation’s operating model is to any other organisation’s. Some consultants and BPO suppliers are very happy for a client to spend lots of money with them on the design of a new operating model from the bottom up, but to a great extent, HR is HR, Finance is Finance, etc, regardless of industry, geography and specific organisation. This is especially true for the more transactional activities likely to be the focus of BPO. I have seen the same design teams that do not accept the concept of any local variation within their organisation seem quite happy to be convinced that their organisation’s operating model has to be totally different from any other organisation’s. I do not believe this is true. Yes, maybe 20 per cent of an operating model is specific to a particular organisation and has to be actively designed for that client. But the rest is already out there and pretty freely available.
• Ensure your Design team considers true best practices. The aspiration of transformational BPO is usually not only to introduce a standardised way of working across an organisation, but also for this way of working to deliver a step change in effectiveness/efficiency compared to the as-is. There are some genuinely exciting innovations in the market and whilst these might not all end up being incorporated into a client’s operating model (one size may not fit all and there is always a question of leading edge v bleeding edge), at least they should be made available for consideration. For example, Robotic Process Automation (RPA), Artificial Intelligence (AI), the various technology components now available “as-a-service” and some truly powerful analytics. If a Design team is not bringing forward these types of best practices, it is time to question the value being added.
• Project manage the design phase. It is usually not a matter for debate that good project management is required in the Implementation phase, just as it isn’t that good operational management is necessary in the Operations phase. However, I have seen the Design phase of some programmes progress in what seems like the absence of any project management at all. As if Design was some kind of art form not subject to management control. But I guess even Michelangelo was working to a budget and a timescale when painting the Sistine Chapel. Notwithstanding the points made in the paragraphs above, a significant amount of budget is going to be at stake during the Design phase, and the milestones of the later phases of the programme are obviously dependent on the design being completed on time. Without proper project management, time and money will haemorrhage to the extent that serious sub-optimalities have to be endured downstream – release of solutions that are not fully thought through, key resources cut from implementation teams and operational go-lives that are forced to occur before they should.
The FitGap phase
FitGap sits between the Design and Implementation phases. It compares the new global model with the existing local practices in each organisational unit in order to identify the differences (“gaps”) and determine what actions are necessary. It usually takes the form of a facilitated workshop attended by the global Design team and the local communities. As mentioned above, there will always be tensions between global standards and local realities and because FitGap is where the rubber first hits the road in this regard, it can be quite a sensitive time.
The key lessons:
• Master the methodology. All gaps fall into one of a small number of categories. For example, items where the local practice has to change to accommodate the new global model (often called “impacts”), items where the local practice is thought to be unchangeable for some insurmountable reason (often called “exceptions”) and a couple of other types. This categorisation is crucial because the different types of gap are processed in different ways – for example, impacts are passed to the local team to get on with planning the specific actions required, whereas exceptions go into a formal review process (see below). But time and again I have seen the categorisation not fully understood by key players in the programme. To be fair, there are grey areas between the categories that take brainpower and experience to figure out, but mastery of the methodology always allows the right decision to be made. This mastery comes only through sound thinking, proper preparation and accumulated experience on behalf of the leaders of FitGap. Without such mastery, the local communities can get confused (genuinely or deliberately) and gaps end up missed or in the wrong categories. This is always going to cause trouble – for example any exceptions not properly identified at FitGap are sure to pop up as extremely unwelcome guests at the party later on.
• Focus on the to-be. I have noticed a tendency for FitGap facilitators to start proceedings by asking the local community to describe the “as-is” ways of working. This may be because the facilitators feel it is a sensitive way of initiating dialogue and showing respect. It is also the natural consultancy modus operandi. In actuality, however, the practice wastes time and sends the wrong signals. The mission of a transformational BPO programme is to implement a global operating model in as pure a form as reasonably possible. Certain elements of the as-is are going to be pertinent to this goal, but only in the light of the to-be. The as-is is not at all interesting in its own right – the majority of it is going to be eradicated anyway when the new design is introduced. In similar vein, it is best not to invite people to represent the local community who have for many years been performing the process in the “old” way. Unless you want to hear in excruciating detail how things have been done for the last X years and why they cannot possibly change. Yes, knowledge of the current ways of working is required, but so also is the ability to accept that change is coming and contribute in that spirit. If really deep knowledge of the as-is is required, it can always be accessed on an on-demand basis.
• Set up strong governance around local variations. Any proposed exceptions emerging from FitGap are potential departures from the global model and they therefore need to be scrutinised closely. Such items should be reviewed and decided upon by an appropriately informed and empowered governance body. This is also true of any open questions arising from FitGap that the global Design team could not answer at the workshop (another category of gap often called “Clarifications”). Unfortunately, I have experienced this process as anything but smooth – lack of clarity on what format of output is required from FitGap, unclear responses provided by the governance group, long delays etc. As a result, confusion abounds, confidence in the solution is eroded and momentum in the programme is lost. Assuming an effective and efficient process can be put in place (and to do so is not rocket-science), a really good practice is for the facilitators of FitGap to spend time cleansing the output documentation before it is formally submitted. This is not to modify the content of course, but to ensue that it is totally clear and therefore fully accessible by the various parties that are going to use it. It takes real commitment and professionalism to spend an additional hour at the end of an intense day carrying out this activity, but it certainly pays dividends.
• Anticipate “local solutioning”. Any approved Exceptions will exist into the to-be environment alongside the new global model. This is also true of any other variations to the global model that emanate from the other gap categories that I referred to above but did not describe in detail. How this residual as-is activity will be “woven in” to the new landscape will need to be thought through. For example, who will perform it (the client or the supplier), how will the old processes connect to the new ones, how will the data get into the new systems? This localisation is crucial – both the local and global elements of the future operating model have to work and they have to work together. It is therefore essential that the programme anticipates this effort and provides the necessary time and resources.
To continue reading, click here.
About the Author
Howard Spode has worked in BPO since the mid-’90s when the industry began. He is hands-on familiar with every stage of the life-cycle, from all angles of the market (client, supplier, intermediary), in numerous geographies, sectors and business functions. He is the Managing Partner of BPOpronet, an organisation that provides advice and support to help BPO initiatives be evaluated, initiated, implemented and operated.