Bridging the gap with X|R|M™
The co-founder of i-Realise and I both came from an IT background. In a previous company we developed a systems development methodology which aimed to ensure computer systems support the objectives of the business. Way back in the 80’s we realised that the key to this was supporting improvement of business processes – long before it was fashionable! The i-Realise approach to process-led transformation (X|R|M™ – stands for Transform) grew from this work, with a change of focus from being an IT-led, business-oriented systems development approach to being a fully fledged business analysis and transformation approach.
We realised early on that just changing processes can deliver continuous improvement, but delivering step change requires transformation of all the elements of the operating model that enable effective processes, including:
- Who does what in the process and organization structure
- How the process is automated (both traditional systems and, now, RPA)
- The skills and competencies needed to operate the process
- Where the process is carried (geographic distribution)
- Measures and incentives
- Policies and business rules
X|R|M™ can be used both to improve individual processes or transform whole operating models. Either way, buying or building software needs to be based on the processes the software is going to automate and the benefits it will bring in improving those processes. This can be thought of as a pyramid:
Another facet of X|R|M™ is the ability to support vision-led or problem-led change. Vision-led change requires someone with a vision – X|R|M™ can be used to capture and articulate this vision and then incorporate it into a re-designed operating model. If there is no clear vision, X|R|M™ can be used to identify current operating issues, analyse root causes and re-design the operating model to address the root causes.
Here’s a couple of examples from our work with CoreLogic that help illustrate this:
- AVM. This was an example of starting with the whole operating model but with no overall vision, therefore it was problem-led. There was a view that AVMs could become a cash cow, so resource was removed from the area. In reality the processes were badly broken and the area only worked (to the extent it did) because of people fire-fighting. When the people were removed, the processes broke down completely and customers started threatening to leave. We formed a team with David Diel and Jon Wierks and redesigned the operating model, including processes, organization and applications. We defined a 3 step program to implement the new model – step 1 stopped the bleeding, resulting in Susan Alan being recognised with an industry award. Steps 2 and 3 required significant investment and have now been implemented, resulting in a stable, scalable operation.
- CondoSafe. An example of designing a single process, based on a vision. This new product was designed based on significant customer research, meaning we had a vision to design towards. We worked with the CondoSafe team to develop a single order to cash process, which was used as input into the systems development effort and for setting up the operational process.
The output from X|R|M™ can be at different levels, depending on how it will be used. For instance it can be a reasonably high-level set of requirements for package selection, or down to the level of business rules and task descriptions for input into systems build.
A critical element of X|R|M™ is engagement with the business. The business is involved in the analysis and design from the start. This means that the solution will be practical and bought into by the people who will use it. We have codified X|R|M™ into a set of training modules which can easily be taught to Business Analysts and our approach is to work shoulder to shoulder with our clients – often in mixed business analysis teams, coaching and transferring skills as we go.
Three other areas where X|R|M™ can play a key role are:
- Supporting M&A integration and divestiture separation – we are currently working with CoreLogic on both of these. We have more case studies:
- Rationalisation of applications, processes and organisation. This is useful when an organisation has evolved in an unplanned way – especially if by acquisition. In this case there can be different processes, systems and departments delivering the same business capabilities. For example, at CoreLogic, we helped the insurance business rationalise 12 customer support processes, involving different teams and different support software down to one process, one central team and two pieces of software.
- Robotic Process Automation (RPA).