Are Target Operating Model design projects still worth the efforts

TOM(Target operating model) design projects use to be the major offerings for Strategy&Operations practise. After the as-is and to-be assessments, consultants most likely will come up with a set of rather convincing suggestions. Usually the industry specific framework and methodology are the keys to crack issues and bring senses to findings. However in recent years, some of the trends indicate that companies tend to skip this exercise and just going directly into either system implementation or integration. It is tempting to do so by having vendor selection as the first step and outsource all the configurations/developments, after all, nowadays the majority of the user requirements are well covered by previous implementation cases.

The danger of it? Disjunctions between joints in operational process flows to a minimum, major disruptions expected at integration points, key milestone delays and delivery quality compromised. Some may argue, what if it is a self contained standalone system. True, but when it comes to information inflow and outflow for exchanges, the cost is time (for prolonged decision making) and output accuracy for a start.

What is target operating model to be exact? In the consulting world, it is a set of framework that provides future state of organising and operating, which is not only limited to people, process and technology. Simply put, it defines organisational scope and governance. Usually we use a standardised template for baseline, and adjust to fit for purpose depending on companies' maturity, initiatives focus, industry specifics, etc,.. Being able to articulate the vision and strategy is only at step 0, it almost becomes condescending for executives to look at consultants as their comments penpals at the mission, vision, value proposition page. I remembered vividly during a RFP response clarification meeting, a boutique strategy consulting firm challenged the host saying "I don't even see the necessity of implementing a system after your problem statement."

Well it's not all that extreme. Certain leeways should be given to different organisation units.

Another struggle often observed would be oversimplifying the initiatives that are not technology driven. Let's leverage a sample framework that adapted from leading practise. A company wants to examine and improve its innovation potentials in areas of the global markets they operate in. Right before taking the topic to the management team, we were brought in for some initial assessment discussions. Usually approved projects placed much focus on conventional growth mechanisms such as organic and inorganic choices, innovation capabilities was never the priority. The stakeholder was quite keen on having a new dimension for the project charter. He already had certain exposure on idea management.

Twofold identified to call out on innovation levers. A). optimising core and B). finding new growth paths.

Levers under category A mostly focuses on existing innovation capabilities, e.g. R&D productivity improvement, global R&D network optimisation, complexity reduction and product quality improvement. While category B focuses on branching into new areas like business model innovation, solution expansion, open innovation, co-creation, incubation and corporate venture.

Arguments for these types of projects are often weakened by non conventional ROIs. Does the output only contribute to intangible assets? After assessing the common supporting layer from process and governance perspective, the ask from the management team was transitioning to commercialisation, which deemed to be achievable by validating the support of business, technology and execution readiness.

So to conclude whether a target operating model is necessary, the answer is YES. It is a prerequisite for system implementation projects and cannot simply be replaced by business analysis documents.