Plan your business transformation but implement it in an Agile way

If you already have some ideas about automating your business processes with artificial intelligence (AI), but don’t yet know how to structure the entire transformation, this article may be of interest to you. It explains the basics and context of a transformation program, target architecture and Agile implementation projects – in the context of examples of AI automation in the insurance sector. 

What is planning in Agile

When I talk about planning a transformation, some people often respond with the misconception that there will be no Agile implementation. The Waterfall approach implies planning, but no one prohibits planning in Agile. Let’s think about Scrum: the question arises how it is different from a Waterfall approach project. First, you select backlog items for each sprint – that’s part of planning. Who plans the solution design? That’s the product owner. Although it’s up to them how they plan, they are responsible for selecting and approving the backlog items. The story points are also a part of planning.

Target architecture vs Agile

Who plans the target architecture in Agile? It is outside the scope of the Agile/Scrum methodology, which focuses on incremental delivery of pieces of working software. Scrum teams or product owners can identify changes to the target architecture. However, full planning and management of its delivery should be the primary responsibility of the Business Transformation Manager.

Why plan a target architecture?

Almost everyone knows what needs to be done to build a house, so this serves as a vivid example of what changes when moving from a small to a large IT project. Not planning the target architecture and respective transformation might result in little synergies and more interim solutions resulting in higher costs, weak governance resulting in deterioration of new competitive knowledge, missing opportunities of what AI may enable business-wise, and as a result – diminishing motivation of employees and slower transformation pace.

Incremental TOM (Target Operating Model) delivery

One of the goals of business transformation management is to deliver the target architecture/target operating model (TOM) piece by piece so that they fit together well. It may simply be impossible for the project team to identify such requirements. Program management should communicate appropriate objectives for the target architecture to the project team, but also be open to feedback and negotiation with the project team.

In many cases, the organization is not able to define the complete and detailed vision of the target operating model at the very beginning. However, it can plan activities to achieve it. For example, if you find that you are unable to select a decision management system because you have just determined that you know little about the features of an appropriate decision management system and your future needs, you can plan how to acquire that knowledge and when to return to system selection. In the meantime, discuss with architects and project teams what might be an interim solution.

Insurance examples

Let’s imagine automated AI-assisted reading and processing of information from documents provided by customers or external partners in the claims process. Architecture decisions and assumptions may need to be made for the following to optimize overall transformation, outcomes and costs.

AI tools for initial pre-processing 

Different types of documents may be encountered when processing claims in different risks and business areas. In general, there are different AI tools to recognise specific information. However, there are standard automated activities such as setting up a claim or activity from an email, splitting combined documents into individual ones (required for automated business logic), reduplicating the same documents (e.g. different scans of the same document) and classifying documents. Detailed requirements may differ slightly, but there is plenty of scope for sharing AI tools, training materials, business logic, business processes and system functions.

Outbound communication

During manual claims processing, there may be multiple interactions between a customer and an insurer. If you automate staff activities with AI, the process could be instantaneous. However, you don’t want a customer to receive all the separate notifications at once, because that could annoy them. There may be different logics and parameters, but there should be a similar structure of consolidating and automating outbound communication with customers for different insurance products or customer-related processes.

Decision engine and business rules structure

AI automation may require many new business rules and an enterprise approach to structuring them. The project team may not know what the functions of an appropriate decision management system are and what the business case is for an enterprise-wide perspective.

User interface change

You may need to change the existing user screens so that a case worker can see the information recognised by the AI and approve or change it for cases that do not fall into a fully automated process. You may also need different types of screens for different processes and business areas. You may want to unify the approach, including the business logic and overall screen layout, to standardise the user experience and simplify development.

Dependence on other business processes

If you automate the recognition and processing of information from incoming documents, you may also need information from other areas to fully automate the claims handling process. However, due to the lower requirements of the previous manual process, the information may not be automatically provided in real time and not in the form of structured data, e.g. policy or insurance terms, the status of payments and customer preferences.

Automating the claims handling process could therefore require system changes in other areas such as policy administration, distribution or billing, which could require earlier planning by programme management. In addition, process automation may require corresponding changes in the general terms and conditions of insurance or contracts with partners, which usually requires company-wide coordination and alignment.

Customer experience

AI can automate claims handler activities, which typically occur a day or more after a claim is filed and documents are uploaded. However, AI enables documents to be read and processed a fraction of a second later. This opens up new opportunities to transform the customer experience – through automated support or even instant claims processing. If the company is planning independent changes to the customer or partner front end, it is a good idea to coordinate and align the two projects. Secondly, the insurer may want to ensure that the customer experience is at a similar level regardless of the line of business, process type or distribution channel.

Planning and coordinating a transformation programme versus an Agile project

Let me give you some highlights as a suggestion. Understanding and defining the target operating model, including the target architecture, should be done at a high level of detail so that you can plan the optimal transformation programme. The details of the target operating model, including the target architecture, will be defined in the context of a specific implementation project. 

• Typically, organisations undertake an annual cycle of strategic planning leading to key updates to the transformation programme. This can be supported by conducting analytical and consulting projects to gain insights into specific areas.
• The goals for the target architecture to be achieved by a subsequent implementation project are called the Intermediate Operating Model. However, if the outcome differs from the original goals, the transformation programme should be adjusted accordingly.
• Operational Strategic Assumptions is a term used to describe critical assumptions that may impact the target architecture and transformation programme, including links to corporate strategy and business competitiveness requirements. They can be critical to the definition of processes and system functionality, but at the same time they can be outside the decision-making scope and knowledge of the project team.
• Every implementation project should start with cascading relevant parts of the corporate strategy, the Operational Strategic Assumptions (OSA) and the high-level TOM onto the project scope, i.e. the programme management should communicate and agree on these with the project team.
• As the development team proceeds with the agile implementation and develops processes and system functions, they could bring in feedback that changes the assumptions of the high-level TOM at the programme transformation level.
• Regardless, programme management should coordinate the process of aligning dependencies of an implementation project with other projects in the programme and outside the programme, which may mean defining new actions or even projects to remove barriers.

Facilitating Agile development of AI automation

One could look at this not only from a cost perspective, but also from the perspective of when the Agile implementation development team will be most productive. Easy-to-configure tools, such as a suitable platform with AI models, flexible Cloud native warehouses, decision engine workbench and low code BPMN tools, make it easier for the development team to experiment and gradually develop and test automation concepts.

On the other hand, it is important that the development team is supported by staff assigned to the centre of excellence of the new knowledge and skills. This will be beneficial in both directions – the experience from previous automation projects will be used and the development of the skills of the competence centre will be facilitated.

The fact that you are planning and then managing a business transformation does not change the role of an Agile methodology in the implementation project. However, it can impact the project schedule, goals, scope, and backlog. Overall, it should make the development team more productive, and the solutions bring more value to the business, especially in the long run.

Piotr Kondratowicz

Business Architect at Sollers Consulting