10427 The Retailer Autumn 2018_Final Draft Pages

Make Time for TOM

Melissa Horowitz Principal Consultant cmg

HOW TOM CAN SAVE YOU TIME, MONEY AND PAIN It’s no secret that Transformation programmes can be painful, expensive and often overrun. This is more likely when programme objectives and the business design are unclear, causing misalignment amongst senior stakeholders. A well-defined Target Operating Model (TOM) helps deliver the business case and paves the way for future continuous improvement. Plan ahead Often on IT-led programmes, the need for a TOM is appreciated too late. We’ve joined many programmes heading into testing and training, not exactly sure what to test or train. Programmes often cut the design phase short, trusting their business representatives to put the new processes in place without lots of documentation. By defining a TOM up front, you will be sure to achieve the stated outcomes, and your teams will know what changes they need to make. The TOM needs to be simple, clear and easy to understand. Meet TOM TOMs define how the organisation will operate after the change is complete. While business representatives are usually knowledgeable about their process areas, the touchpoints between functions are less obvious. Developing a TOM also gives the organisation a structured approach to work through these touchpoints and core business scenarios so it can understand how it will operate when the initiative goes live. Our favourite framework for a TOM breaks it down into four

govern the programme’s delivery. During the design, any risks, issues, assumptions and dependencies are circulated throughout the wider business to gather the support needed to address any gaps in direction. TOM sets the scene A TOM defines the new ways of working for the parts of the business that are changing. One of the first steps in developing a TOM is to define the scope of the processes that are changing, often against the value chain (the end-to-end processes needed to run the operations). It’s critical that the business defines the processes needed to run the organisation in the language that they use to talk about them, so that everyone buys into the value chain. The value chain should cover all the operational activities. So, when the value chain is marked with the programme scope, the organisation clearly knows what is in and out of scope. TOM speaks the LANGUAGE OF BUSINESS AND TECHNOLOGY Just as the value chain needs to be in business language, so do the process maps. All too often, we’ve seen IT-led initiatives produce systems process maps, not business process maps. A business user should be able to read a process map and understand how they will carry out the process, the roles and systems involved and which parts of the process they support. The process maps should provide IT with the business context for how the technology will be used. TOM is a team player Large organisations are generally siloed and some of them replicate this way of working on their programme teams. These teams produce process maps whose touchpoints have not been worked through or, even worse, processes for just one or two functions. The function owning a process map needs to agree all the steps they have defined with ALL the other functions involved in the process. Along the same lines, a TOM cannot be defined for one function in isolation of the others. Each function depends on the others for inputs and outputs and the other functions need to sign up to provide them. TOM will save you time Once you have developed a TOM, developing the next one is that much easier. Recently, we worked on a project with a team who had just completed a Transformation. In the course of our work together, we were impressed with how well the team knew their business processes and the touchpoints with their colleagues’ processes. The design work that usually takes four to five months took only two. Since the team already had established relationships with the business, open questions were quickly

components: • Solution • Processes

• Organisation structure • Skills and capabilities

Simply put, to design a new way of working, you need to design each of these components and how they interact. The objective of the documentation is to align the programme team and wider business to prepare for the change. Really, the TOM is a communication tool. If everyone has a shared understanding of the TOM, that alignment is easier to establish and ultimately easier to implement. T stands for Target We’ve seen some programme teams struggle to know what that target is. This can be due to a lack of vision from the business or the volume of change in the organisation. The TOM documents the business design needed to deliver the stated benefits and

20 | autumn 2018 | the retailer

Made with FlippingBook flipbook maker