Joe Ales & Jason West
Season 2: Episode 10 – Target Operating Model Design
Jason West: Welcome to the Underscore Transformation Podcast. My name’s Jason West.
Joe Ales: And my name’s Joe Ales.
Jason West: And together we’re the founders of Underscore. In season two, we’re focusing on implementation, and the challenges that surround making changes to policies, processes, systems, or team structures. If you’d like to know more about scoping a transformation programme, please take a listen to season one.
Today, we’re going to talk about Target Operating Model design, and this is something that you will have ideally already started during the scoping phase of your transformation. At the very least, a set of assumptions would have been made about the size, shape, and cost of your current operating model, and how that’s going to change as a result of your transformation. Ideally you would have based it on some sort of benchmarking data.
However, it is certainly not unheard of for a transformation programme to be approved in part, at least, on a commitment to reduce headcount costs, but with little real understanding of how this is going to be achieved. So, whether your business case is based on a detailed bottom up cost analysis, or a top down cost reduction commitment, in a business case you should really resist the urge to dive straight into designing systems and processes until you actually reach consensus on young target operating model design.
So, Joe, let’s just start at the beginning. What exactly are we referring to when we talk about an operating model?
Joe Ales: Well, the first thing is there are perhaps as many definitions as there are people selling management consultancy services. But let’s keep it really simple, and it is quite simple. An operating model is a collection of capabilities – and this is people, process, and technology – that an organisation deploys to turn the vision or a strategy into it’s the products and services that delivers a specific set of values to its customer base. So, transformation is really the process of turning one operating model into another; so your current operating model is your ‘as is’ and your desired future state is the ‘target operating model.’ You might hear people refer to it in lots of different ways, but it is really simple. There are people out there trying to overcomplicate the concept of operating model but that’s what it is.
Jason West: Got ya, and speaking of simple; much like the transformation process, target operating model design is a process, and it’s a relatively simple one at that, isn’t it.
Joe Ales: Yes, if you follow the right steps, and it is a simple process, but you can get into an awful lot of trouble if you don’t follow a sequence. And at points organisations and or functions can jump into drawing organisation charts, because there’s a belief that “if we change the organisation, that’s the transformation, that’s changing the operating model.” And really that is a dangerous grounds to be in.
Jason West: So, that’s what not to do: jump straight into thinking about organisation design, rather than operating model design. What is the right way of approaching target operating model?
Joe Ales: Effective target operating model design really starts with understanding your current state: how effective and how efficient your organisation is today. And we’ve talked, in previous podcasts, an awful lot about that already and especially in season one; building your case for change and your transformation strategy etc. So, you’ve really got to understand, to have answers to those key questions: “what does my customer think of the services I deliver? And how efficient are we at delivering those services today?”
and we’ve talked about benchmarking etc. in previous episodes.
Then there’s the piece around culture; “what culture do we have in and around our organisational function? What is our strategy today? What is that people capability today?” And when we talk about people capability we talk about also systems, processes, and clearly structure has a role to play in it; how do people interact within the organisation, within the operating model? That is a component of a much larger set of activities, and those are components that need to be factored in, when you’re designing your operating model.
So, yeah, do not fall into the trap of going straight into organisation chart design, and putting names in boxes because that is really not the right thing to do. The other thing to consider is not doing this in isolation. It’s not just about the function transforming, or the business transforming, it has got to be a set of business requirements that are forcing you to change. It might be gaining further efficiencies, there might be external factors putting pressure on the organisation to change, and we’re in a period of COVID-19 now, that undoubtedly will have a profound impact on organisations in years to come. These external factors are putting pressure on organisations to change, so what are those driving factors? You have got to spend time really understanding what what’s the business trying to achieve? What are the business requirements? And those need to feed into your target operating model design.
Another really key point is, what’s the vision for the future? And we talked about this in previous episodes, I think we dedicated a whole episode to creating a vision and strategic objectives of the programme etc. So, you’ve got to really have articulated that before you start implementing your new operating model. You really need to understand what is it that you’re trying to achieve in the future, what are your strategic objectives? And keep those in mind along the way on this transformation programme. Also, what are the principles that govern those design decisions that you’ll make? You need to agree all of that up front, before you start embarking on a design of the new operating model for your function/business.
Jason West: And ideally you would have completed this as you scoped out the transformation. But if you haven’t done this already, and you’ve secured budget and you are you ready to get going, then please go back and do this. Go back, engage the business, understand their requirements, do some benchmarking ideally, as it gives you a baseline to work from, make sure you’ve got an agreed vision, strategic objectives, and design principles that the leadership team have really signed up to.
So, let’s take that as our start point. We’ve done all that work, which might be before the investment decision, it might have been after. But let’s just take that as our launch point; what do we do next?
Joe Ales: Like we talked about earlier, it’s a process isn’t it? I think if organisations follow this simple process, this simple methodology, they are likely to get it right.
It’s a series of structured design workshops, that are facilitated by someone with a little bit of experience in TOM design. They need to have that to just guide those individuals through the process, to avoid jumping to org charts and putting some paragraphs and some bullet points against each of those boxes, in an organisation chart, to describe what that role is for. Because that is very, very superficial design of an operating model, and if you don’t go into the detail you will have all sorts of ambiguity and confusion further down the line.
So, you start with a series of structured design workshops, and the way we facilitate these sessions, is typically, in a room we will have individuals, members of the senior leadership team, of the function being transformed. Because, let’s be honest, there are people that are going to be involved in designing that target state, and you need to be very mindful of who you have in those design sessions. It needs to be selective bunch of individuals who have a very objective view of designing the right operating model for the business, and no empire building etc. You have got to be very mindful of that, you’ve got to go in with a set of principles when you’re making these set of design decisions from the outset, and if you’re unsure whether a person should be in the room, if you really unsure, perhaps don’t involve them at the very outset. But that needs to be really carefully thought through.
Jason West: I think the other point, in terms of who should be involved here, is you’ve got to get the process owners involved in this as soon as you possibly can. And you might not have them identified right up front, but if they aren’t plugged into this, and we’ve seen it happen in certain projects where the target operating model design was divorced from the rest of the programme. And you had process owners doing really great work, and designing new solutions, new ways of working, but the target operating model design had no visibility of what they were doing, and they had no visibility of the TOM workstream was doing and it was just a mess.
Joe Ales: Yeah, absolutely. In an ideal world you do some of the TOM design before you start getting technology configured. It’s a real prerequisite that you do TOM design before you start doing process design on systems and technology. Because you’re in danger of having to unwind an awful lot of it later. More importantly, in danger of having the tail wagging the dog, which is where the technology starts to drive in your operating model design decisions, which is not the right thing to do in any case.
So, this is a series of workshops, with a number of stakeholders, and if you’ve got the process owners identified, absolutely they are critical to designing aspects for the processes that they will be accountable for. And then there’s a series of workshops within a week or two, in between each of those workshops, as we design a set of activities, review them, socialise them, and we will probably be going into a little bit more detail on what those activities are, later.
It is like a little bit of a gated process. Let’s not design everything all at once, to then have it reviewed, and have to redesign it again. You do a bit of design, validate it, sense check it, say “okay are we on the right path? Does this make sense for the business? Is this hitting our business requirements, our vision etc.?” And then you go into the next level, the next iteration of design, which is probably a little bit more detailed, and so on, until you come out the other side with a clear set of roles and responsibilities for the about organisation. And when we talk about organisation it can be enterprise-wide, or it can be just for a particular function.
Jason West: And it is very much about starting from those bigger building blocks; make sure everybody’s agreed on the foundations that we’re working from, getting them signed off, then the next level of granularity, and then if you get finer and finer as you go through different stages of the design process.
So that’s the structure; what about content as we look into these target operating model design workshops? Let’s talk about the first workshop; with what typically would be included?
Joe Ales: The first workshop is used to identify, what are the elements or the components that will make up your operating model? But what do we mean by that? So, for example, our operating model will consist of or contain a shared service for a business services organisation, it will contain some local operations and it will contain maybe business partners or centres of expertise.
So, at macro level that’s what our organisation is going to consist of. Then you need to describe what are the attributes of each of these building blocks, of these components? For instance, shared services or business services will be accountable for quality of service delivered to customers, and responsible for driving process efficiencies. They don’t necessarily own the process, because the process owner makes it somewhere else, maybe in the centre of expertise, for instance. But they are accountable for delivering those processes seamlessly and as efficiently as possible. So, they will have a role to play in making the process more streamlined, so they can feed in to the process owner, and say that “this processes isn’t streamlined” and they will have accountability is to execute those routine transactions in a routine way. While the process owner is accountable for the process, which may set in the centre of expertise, for instance, maybe it will be accountable for the effectiveness of that process; is it delivering the value to the customer, to the organisation? Is it delivering customer satisfaction? Is it delivering increased profitability? Whatever the process owner is accountable for. So, at a macro level you need to define these key attributes for each of your building blocks.
Jason West: And you’ve also got other dimensions, as well, potentially which it’s really important to get on the table early, whether that’s a geographic dimension, or a business dimension. You might have a business unit view, or a division view, and things might be different at a country level, compared to regional or global level. So, all those dimensions need to be really thought through, up front, before you start heading off into the various details of “what’s the purpose of this? What are the key attributes of that?” Because you can become unstuck if you design everything with a completely global approach if there’s other important dimensions to your organisation.
Joe Ale: Yeah, and clearly the maturity of different markets around the world will, to a certain degree, drive your operating model design as well; we’ve experienced this before, and you have to be mindful of that. There is no such thing as ‘one size fits all,’ you’ve got to really be mindful of different geographies, different cultures and different levels of maturity in countries around the world.
One of the other things that you need to think about, from the outset, is what’s the scope of your organisation? What are you talking about in terms of process? What are the processes that are going to be in scope, that you’re going to design? Who is accountable for what? So, maybe, if your organisation doesn’t have a process taxonomy of kind, use one. Because that allows the workshops and the design thinking to progress in a more structured way, rather than developing things on the fly. I just helps, almost like a checkpoint, by going back to a taxonomy, to say “have we thought about all the processes and all the capabilities that we require to deliver an effective finance function, or HR function, or IT, procurement function etc.?” Have something like that in the back of your pocket, because it will come in very, very useful.
Jason West: And then once you’ve got that process taxonomy, I think in that first workshop you will hopefully have the individuals in the room that will become your process owners, so the people who are accountable for efficiency and effectiveness of processes. You can then start aligning things; saying “these processes belong to these individuals, these people carry out these particular roles, head of whatever function, they are going to be the process owner for these specific processes.”
So, you start creating the boundaries the those really clearly defined accountabilities, and make sure nothing is falling between the gaps. Doing that as early as you can, and getting those named individuals in the frame for those particular processes; it’s really important to do that as early as you can.
[Intermission: you’re listening to the Underscore Transformation Podcast, for more practical guidance on transformation, you can download our free transformation checklist. Visit our website underscore-group.com.]
Jason West: Which brings us onto this concept of RACI, which I think many people listening to this will be familiar with. But one of the things we focus on, when actually designing an operating model and aligning responsibility to some of these processes, is the R and the A.
So, we tend to focus primarily on that, and being very clear about who is accountable, and obviously that can only be one role. In the rules RACI you can only have one person accountable, but a few people responsible. So, be very clear where the accountability sits for that particular area, process, or capability.
And where a lot of organisations stop, which is interesting, is they tend to categorise an A to a role or an R to a role and then stop there. And frankly, that’s not enough. You’ve got to go to the next level of detail, which is, “okay what does it mean in layman’s terms? What will the person physically be responsible for? What will they be physically accountable for?” You need to be really be prescriptive and go to the next level of detail, and actually start writing down that “this responsibility means XY&Y” so that when later down the line somebody raises alarm and asks “have you thought about XY&Z?” You can say “yes I have and that sits over here, for these reasons.” And clearly you can iterate it, you can adjust it, but don’t stop at just categorising areas of responsibility with As and Rs.
Jason West: But that’s not what we’re doing at this stage, though is it? It’s really important that that happens, but that doesn’t happen here, because if you try and jump into that now, it’s too early in the process. You will have stepped over a number of important steps. So, the first thing that you have got to do is get that matrix together, that has your processes on, and your various operating model components, your integrated programme teams, your centres of expertise, whatever it is, whatever those components are, and then populate that RACI at the very simple RACI, those letters, and getting that into a structure that actually you can start making sense of, by drawing things in simple terms.
Joe Ales: Absolutely. But the point is, it doesn’t stop there. A lot of transformations think that’s enough and it isn’t.
Jason West: Absolutely, a lot of organisations thing that it stops that, but it absolutely doesn’t. Because it’s only certain people who will use that. And actually sense checking that that RACI matrix, by drawing out the interactions on sheets of paper to say “okay if we take a focus on our on our shared service, what are the different interactions they’re going to have with these different groups? And how do we see that working?” And just looking at that picture and asking, “does this actually makes sense; what we what we’ve written in an Excel table, when we draw it out, does this actually makes sense?”
Joe Ales: Yeah, and it’s more important, actually, for the whole customer experience. What is that customer journey going to look like a the particular process takes somebody through three or four or five different touchpoints as well? So, you have got to just think about that. If the shared service has three or four different levels of interaction with different functions, and at the end you’ve got a customer that has to go through a whole bunch of loops, it is important to bear that in mind as well. Developing an interaction model is really, really key. And that again, is your first iteration of design, that may well change. But you’ve got to have that, almost the ambition of what’s my ‘to be’ interaction model going to look like? How are my customers going to deal with a process? And customers can be internal, external customers, how are my customers going to deal with this function? Are they coming straight through to a shared service, or are they going through a local representative first and then going to a shared service? And it might be crazy point, but I’ve seen organisation designed like that, where the shared service is really just a back office operation, rather than front office operations. Are you dealing directly with its customer base? So it’s important to have those interaction designs up front, and again, as you get more clarity in your roles and responsibilities etc. and as you evolve your RACI further, at that point it might become clear that actually we’ve not designed enough into shared service, we need not put more into shared service or business services. Or perhaps, that we were not being brave enough with how much activity we put into a business services organisation, at the fear of relinquishing responsibility from the line, and from business partners or centres of expertise, whatever it is.
So, this interaction model really helps you shape it and say, “okay this is our ‘to be’ organisation.” And it helps you just keep that framework in mind as you design your RACI.
Jason West: And I think a really good point to end these first workshop is where you’ve got people diving down into the detail of RACI, and then up a bit looking at the interactions of the various different parts of the model, then try and bring it together at the end and create a unified operating model on a page. A diagram that really shows how work is going to flow through the organisation at a high level, how value is going to get delivered to customers.
What you would typically end up with is a number of different versions of this, because you typically have breakout sessions, or some people work on it. And this is a good example of the follow on work that happens outside of the workshop, because somebody is going to need to take those different model on a page pictures and take the ‘best bits’ from them, and combine them, simplify them, tidy them up, into a maybe a few of different options of that single diagram, and then go and sense check around the place, get people’s feedback and input and iterate that design.
So, that’s often a good point to aim with the first workshop, and a lot of this stuff tends to be quite fluid; you can’t say “absolutely we must get to this point in the process by workshop three.” You are dealing with complex solution design here, so you’re going to iterate your way through it, so don’t worry too much if you don’t get there by the end of that workshop. But it’s a good objective to have.
So that’s workshop one. In the next workshop session, Joe, what have you got for us.
Joe Ales: First things first, review the output from the previous workshop, and any updates or decisions that have been made. Because like you talked about before, this is a good opportunity for people to walk their design around the business, test it etc. And they are going to clearly come back with a set of views or as to whether that the ‘organisation on a page’ will work, whether that first idea of RACI will work.
And then next we need to turn a matrix full of Rs and As into their meaningful sentences. Like we talked about before, it’s at this stage that you are really going to start creating those paragraphs, and this is a really important activity to do. Which is, perhaps, where many organisations stop, and hence target operating model projects fail, because they don’t tend to focus on this level of detail.
Jason West: Yeah, but these sessions can be pretty tough going, can’t they. Because you’ve got senior people in the room and you’ve got them focused on a large amount of detail, which, generally, senior people really love.
Joe Ales: Yeah it is difficult to get individuals through these workshops, but if it was easy I guess it would be done well all the time, right.
Jason West: Yes, true, people wouldn’t just skip this step and jump straight to drawing org charts and writing job descriptions. [LAUGHS].
Joe Ales: But this is important, and it is it is key to keep that stamina going.
Jason West: Yeah, you’ve got to keep people motivated and focused, and actually facilitating these sessions is quite tricky. And that’s where having somebody that’s got some experience in doing this is useful, because there will be a lot of push back. There is always a lot of push back to get people to do this, they just don’t trust the process quite.
Joe Ales: Yes, it is a real leap of faith for some. And you need to encourage people to trust the process, because actually it will pay dividends later on. Members of the senior management team don’t often enjoy this particular session, but it is key that this is done. They are hard going, and the other thing that you start to do at this stage is also numbers: ratios of headcount, the numbers of FTEs that are going to be needed, now that you got an idea of who is responsible for what. Because responsibilities will equate to effort, so you will start to have an appreciation of the number of heads that you will need in a particular component of your target operating model.
And if you have done benchmarking activity before, when scoping your project, which again we were highly recommend you do, that can provide a little bit of a compass to guide you through “what’s the appropriate number of heads to deliver a particular process? Are we over baking this process, are we gold plating it where we don’t need to? Perhaps we need to divert more headcount to other parts of the operating model that require more effort?”
Having somebody on your team, like a client advisor, that has access or knowledge of how other organisations have set themselves up and has an idea that can help your design thinking, absolutely you need to you need to consider that.
Jason West: Yeah, and having somebody that really understands the technology that you’re about to implement, and what that does to an operation once it’s live. Because there’s a set of assumptions that you’re going into this design with, “we’re going to be able to automate processes here, we’re going to be able to streamline stuff there. We are going to need more people over here because this is new work that we’ll be able to do, because we’ll have new data or insight or whatever it might be.” Having that real operational experience of how this technology operates in other organisations, in the real world can be really, really helpful in informing those assumptions that you’re making.
Joe Ales: Yeah. Otherwise you’ll be making a whole bunch of assumptions that have never been materialised:
Jason West: “It’s going to make the tea for us, it’s to go out there and cure world hunger, and it’s going to be the panacea of all systems.” [LAUGHS].
Joe Ales: “It’s going remove all the human effort needed to do things.” Yeah, well, it may do elements of it, but it won’t do it all. So, yeah, absolutely having that expertise in a room will really help.
Jason West: So, to recap; the output of this TOM design work is going to be a diagram of your operating model on a page, descriptions of its various components and how they interact with each other, an organisation chart, and there will be an organisation chart that comes out of this that the shows numbers of roles. But also detailed role profiles that describe, in really plain language, all the accountabilities, responsibilities of those roles and how they interact with each other. And the documented volume assumptions and staffing ratios that you’ve used to calculate the number of staff than you actually need to populate this operating model.
Joe Ales: And this is what we describe as your ‘target operating model prototype zero.’ And it’s an absolute prerequisite for any detailed systems and process design. So this is the work that needs to be done prior to getting a system integrator into the room.
Jason West: Yeah; we’ve seen too many design teams that go into the system design workshops without having these fundamental building blocks in place. And the result is either confusion in the room about who should initiate, who’s going to review this, who’s going to approve it, who’s responsible for transacting these various system processes? And not just causes delays. Or you get process owners who unconsciously start trying to build today’s processes into new systems.
Delays is one element, but you also can end up with decisions just being punted down the road, just kicking the can down the road; “it’s too difficult to figure it out here, we’ll just make a decision quickly and move on because we can fix it in a future prototype.” And we’ve already talked about, in previous episodes on testing and data, in this season, just the cost associated with making design enhancement decisions late in the programme, when you really should be focusing on identifying and fixing defects.
Joe Ales: You’re right, because you should be able to iterate and refine it as you understand the capability of the technology that’s coming in. You’re not setting something in stone at the very outset, because of technology will give you new answers that you wouldn’t have thought about, it will challenge some of the assumptions that you’ve made in your FDE, for instance, “I was under the assumption that we will be able to automate all of these things,” well guess what you won’t be able to automate, you’ll need some manual workarounds or something because the technology won’t deliver the process in a fully automated way.
And that is going to challenge your assumptions, you’re going to have to go back, maybe adjust some levels of FTE, and maybe adjust some roles and responsibilities as it becomes clearer and clearer about how the technology will drive some of your processes. So, this is not to say that your target operating model design is set in stone, like we talked about, it is not, far from it.
So we really refer to this stage, prior to getting systems integrators into the room, as ‘TOM design prototypes zero,’ and that’s because it’s going to change and iterate throughout, and they’ll probably be one or two iterations of designs. You develop your prototype one, prototype two and then once you get to the end of your systems configuration, your TOM will be absolutely aligned to that, and then it’s just a case of implementing both the target operating model and the technology at the same time. Which, for some individuals, might be a frightening prospect. But it’s the right thing to do because you designed a set of business processes in your technology that adhere to future target operating model design decisions that you’ve made, so you’re naturally going to implement the two at the same time.
Jason West: And I think when you get business unit or country design teams really starting to work together, they often end up finding commonality and opportunities to align, to take best practice, to streamline. There’s one element that comes from “well the technology can do this new stuff that we hadn’t considered, or it can’t do these things that we thought it could.” So, that’s going to adjust our operating model, but just the fact of getting people in a room together, that don’t normally work together, and sharing best practice, you actually find the potential staffing ratios are going to adjust because of that sharing of knowledge.
There’s going to be different forces acting on this operating model, and that’s why it’s really important to put the work in upfront. Design it, but don’t be precious about it. Allow flexibility to iterate as you go through. Because one of the real benefits of taking this iterative approach is it provides early reassurance, or sometimes early warning, about the viability of your new organisation, and your new ways of working. And frankly finding out that your target operating model is based on flawed assumption, that’s never a good day, because that means having to go and have a conversation with the sponsor about the viability of your business case. But if you discover it early enough during the build phase, you can course correct, and you can update your operating model design; you’ve got time to find a solution.
Ultimately, it might actually impact the payback period of your programme, or the amount of benefits that you can deliver. But it’s a much easier fix than discovering your process automation assumptions were unrealistic, say three months after go-live and after you’ve made 90% of your local operational staff redundant. That can be a really bad time to find out that you haven’t quite been right on your assumptions.
Joe Ales: Before you get to think about your go-live, you really need to have a word with your HR function, to map out the company and functional competencies of the roles, and then go through the whole restructuring process. It’s not something to take lightly. This is not something you’re going to do in the dark room somewhere, you’re going to have to have cooperation of those individuals that are experienced in delivering restructuring exercises. Again, if the design has been done thoroughly and everything has been well thought through, you’ve got really good rationale for why you’re making decisions to your organisation structure, your operating model, that people will understand it’ll make the whole restructuring process easier too, as you will be challenged by individuals that are doing the doing on the ground. They will be asking you difficult questions about “okay have you thought about this bit of responsibility that I have?” And because you’ve mapped it in your RACI in detail you can say “yes,” you will have answers to those questions.
At this stage of the process, this is where you will see all of the hard work paid dividends, because you’ll see it come to fruition and you can say “okay I now understand why and Joe and Jason have made me sit through these complex workshops, detailed workshops, because when it comes to facing the whites of people’s eyes and giving answers to their questions, and they’ll have operational questions, you have thought those through way back when.”
Jason West: As you’re working through that, what often ends up being a restructure, you’ve really thought through those key performance indicators for the role. So, when you come to do your impact assessment, that that’s going to quantify who’s affected, who’s not affected, how are they affected? Potentially that could be a restructure and reduction of roles in certain areas, it’s based on really well defined, and really thought through, design decision that and very deliberate decisions rather than being a bit of a box ticking exercise, where you’re just moving numbers around on the spreadsheet.
That HR implementation plan also needs to take into account local country legislation, trade unions, works councils, all that side of things. You’ve got to really work this stuff through with your HR team, because this is the stuff that can really get you unstuck if you make any missteps here. So, getting them heavily involved as early as possible in your thinking around your changes to operating model design, really important.
Joe Ales: But it’s worth noting that not all transformations will equate to restructure. Sometimes you’re repurposing individuals’ competencies at something else, that is also part of it. “We’re going to operate fundamentally differently” in some cases some individuals may not have the capability to do so. In other programmes it might be actually you put a development plan in place to equip those individuals with competencies and the skills they require, for those role profiles that you defined, and give people a period of time to adjust etc. And actually, try those new roles out before you do something such as a launch a restructuring exercise.
But that’s a whole different episode, where we’d need to invite a bunch of HR employee relations professionals onto. But your pointis important; HR and people function will need to be plugged into any form of operating model design implementation.
Joe Ales: But to your point, it’s not just about moving people’s roles around or reducing headcount here and increasing over there. It’s also improving the capability to operate in this new way, therefore, involving the HR function to look at things like development programmes that you put around this thing. And that’s something that so often gets missed.
Everyone focuses on the technology, because that’s the bright shiny stuff, people worry about process, how are people going to operate in this new bright shiny building, with its new systems and processes? “Well perhaps we should do some training and some development and maybe some coaching and things like that.” And frankly that’s the bit that often gets completely overlooked, so involve HR early, and make sure you’ve got budget to upskill your people and make sure they are supported through the change. Please do that, please, it’s essential in making this work operationally.
So, the final point to consider is the decision around when to implement the changes to your operating model. Joe ,when is the best time to make this change?
Joe Ales: That is a good question Jason. As with many things in transformation, there isn’t a right or wrong answer. There is no ‘one size fits all’ approach, so in global transformation, for instance, some geographies might take a little bit longer to implement the target operating model than others. And also you will have made a set of design decisions within your technology, that will require certain roles to execute those particular processes. So those roles will be required to be live when you go-live with your technology. At the same time, you will need to have those components of your target operating model that are incorporated within those process design decisions, that you’ve made with any technology, that has to be stood up and available from day one. Otherwise your technology fundamentally won’t work.
There are other components, for instance, that might be implemented over time.
Jason West: “We’re going to set up a shared service centre in Manila” for example. That could wait for some other time; you might go before the go-live for technology, you might go after it, you might choose to do it online. But I guess that’s a separate decision,
Joe Ales: Yes, it is. As long as you can allocate the individuals that are due to perform those shared services activities in your business process, as long as you can assign those tasks to individuals within geographies, within countries, within business units, then your processes are going to work. That’s the key. If you’re not ready to implement the TOM on day one, the minute you turn the technology on, who is going to fulfil those roles that you’ve designed within your technology until such point as your TOM is implemented? So there’s the transition period. In an ideal world, if you can go live with it all at once that’s best, but it’s not easy. Target rating model implementation affects individuals, it affects people personally, so it’s something that organisations will be naturally mindful of and rightly so.
Jason West: And it’s actually something we’re going to cover in a lot more detail in our next checklist on transition so that that will be coming up.
We had planned on publishing our transition checklist in the coming weeks, however, given the events that have slightly overtaken us with the coronavirus pandemic, I thought that actually it probably makes more sense to pull forward something that we were going to do anyway. So, instead, we’re going to really focus on crisis management and recovery because, frankly, we’re in a world that’s in crisis, and although a transformation is great, very deliberate, approach to making business change, that’s not where we are right now.
So, we’re actually going to focus in during some upcoming episodes more on crisis management recovery. We’ll be sharing some really practical advice drawn from the British military, and applying those processes and lessons learned to a business context. Our colleague, Lucy Finney, will be joining us to talk to us about that in a bit more detail. But before we get to that we’re going to complete this 10 point checklist on the build phase, with the final episode on governance and control.
Thank you very much for listening this week, and we look forward to talking to you next week.
[OUTRO: Thanks for listening. We really appreciate the support. This episode focused on one of 10 critical success factors in the Build phase of transformation. If you’d like more information please contact us via LinkedIn, or visit our website, underscore-group.com.]