In this series of articles we’ll talk about, first, the challenges in operating enterprises processes beyond tasks and workflows. Second, we’ll introduce Deep Process Automation (DPA), the platform for automating the operations of enterprise processes. Third, introduce a few case studies of where the platform has been deployed across global insurers and its impact. And fourth, the Enterprise Operating System built on top of the DPA platform. 

Operating Enterprises Processes: Challenges

Enterprise operations are function driven, not process driven. Therefore, they are functionally federated. They are designed, built and grow vertically around functions rather than horizontally around processes. This is amplified in geographically dispersed enterprises. Over time, different teams independently make operational adjustments, modify governance, restructure internally, and independently manage their technology and software systems.

This organisational structure is reflected in both enterprise operations and supporting technology.

This setup is most evident in the C-suite. Enterprises have Chief Financial, Compliance, Revenue, Legal Officers. Not Chief Underwriting, Claims Handling, Claims Settlement, Onboarding Officers.

Enterprises are typically structured around the functions and expertise of their teams, such as finance, payments, legal, compliance, and sales. Each team recruits, trains, and promotes its own members, who over time gain deep knowledge of their team’s specific structures, operations, governance, functions, and software systems. While there may be some cross-movement or knowledge sharing, teams are generally siloed, not by design, but as a natural evolution of their setup and the necessity for team members to develop expertise within their specific domain.

This setup results in a greater demand for function-driven technology, leading to a larger supply of specialised systems and solutions for functions such as payments, accounting, compliance, imaging systems for damage assessment, and intelligent decision-making for policy premium assessment.

This is in contrast to a far smaller supply of systems and solutions designed purposefully for end-to-end process operations such as claims handling, mortgage sourcing, onboarding, quote generation and many other processes. Despite the significant role these processes play in the overall operation of an enterprise.

Enterprises are complex organisations that continuously operate many processes to create value for their end customers

Enterprises operate on three levels: Tasks, Workflows (10 Tasks), and Processes (100 Tasks). Tasks typically involve 1-5 tasks, are confined to one operational team, and engage 1-2 software systems. Workflows usually consist of 10-20 tasks, are localised to 1-2 operational teams, and require the use of a few software systems. Processes have over 50 tasks, are dispersed across three or more operationally separate teams, and involve multiple software systems.

Example Tasks include, access data template, populate data template, compare data against rule set, retrieve data from external source, sanitise & normalise collected data, generate & send notification, retrieve document, store data & document, trigger payment, receive payment confirmation. Example Workflows include collect claim data from claimant (22 tasks), verify policyholder identity (16 tasks), policy decision in principle (23 tasks), collect payment details & issue invoice (25 tasks), initiate payment (12 tasks), insurance sourcing compliance (18 tasks).

Enterprise Processes involve several Participants, including different teams, departments, and numerous software systems. Each participant functions with a degree of independence, with their own governance, operations, and often, their own software systems, licenses and set up. Each participant executes a specific step(s) in the process and passes along the results of the execution to the next participant until the process is complete.

We define Process Operations in the context of the Enterprise. Process Operations include, i) evaluate & initiate next step, ii) send data & information to each system, iii) receive response (execution) from system, iv) compute & verify response (execution), v) share & store execution of each step. And repeating this across the end to end process steps. 

Fig. 1 illustrates a Process for settling claims across operating entities within an insurer. A customer buys a policy from an Originating Entity (OE). They, at some point, file a claim due to an accident, handled by a Handling Entity (HE). i) The HE claims team collects and sends claim details to the OE. ii) The OE claims team processes and approves the request. iii) The HE finance team issues an invoice to the OE finance team, iv) they approve the invoice and forward it to their payments team. v) Finally, payment is made to the HE.

Process operation development in enterprises

“Processes in enterprises typically involve multiple participants. When a process is (re)designed, it’s based on the functionalities of these participants, who have efficient operations, governance, and advanced software systems. However, the end-to-end process operation must be consistent and efficient across these participants, especially as they evolve over time.

In (re)developing their processes, Enterprises choose one of two avenues: I) build from scratch, where they identify the teams and functions required to participate in the process, and develop the connectivity and operations for the specific end to end Process as a stand alone project, II) buy and (re)align, where they buy or utilize an off the shelf solution in the market that generically performs that Process. They do this with the intent to (re)align their Process to the capabilities of the solution.

In (re)developing processes, enterprises usually opt for one of two approaches: I) building from scratch, teams and functions required for the process are identified, and connectivity and operations for the end-to-end process are developed as a standalone project. II) Buying and (re)aligning, an off-the-shelf solution is purchased or utilized, intending to (re)align the enterprise’s process with the solution’s capabilities.

Challenges with Process operations development and when they are live

These approaches, both of which are implemented in enterprises at scale, result in a number of inefficiencies. This leads to very high technical and operational resource requirements and capital expenditures. 

I) Enterprises often face numerous challenges with the ‘build from scratch’ approach in process development. In this approach, enterprises set up a dedicated project for a specific process. They work diligently to connect participants and software systems involved in that process, gather requirements from the participants, and adjust the process operations until all participant requirements are met. The rules and operational steps, which mirror the business requirements of the end to end Process at the time of requirement gathering, are then manifested in software code.

There are several problems with this approach. Firstly, each project is unique, with its own decisions, nuances, operations, and technological choices, which are neither scalable nor repeatable. Secondly, the decisions and choices made during the development phase are specialised knowledge that the original project team possesses. However, as processes, teams, operations, governance, and software systems naturally evolve and change over time, this knowledge may not be fully transferred or documented.

Hence, maintaining the process becomes a challenge, especially when the original team goes to other projects or companies. The development isn’t fully documented, and many of those distinct choices and decisions might not seem obvious to the team maintaining the Process, who most often instead of reverse engineering the decisions, choose to develop patches, ad nauseam.

Furthermore, the development is often local, meaning that changes impacting a specific part of the process are rarely reflected in the end-to-end process operations. Typically, organisations are reactive; they wait until a problem arises and then fix it locally, without considering the potential impacts on the rest of the process. This reactive approach results in the proliferation of local operations code, where each part of the process is operated by a local script maintained and updated by local teams.

Due to the lack of visibility across the local teams and silos, over time, divergences become evident in the operations of the process, creating inconsistencies, inefficiencies, and costly frictions. Lastly, this approach often results in a gradual drift between “what executives think the Process is doing” and “what the Process is really doing,” making the operations and maintenance of the process resource-intensive and expensive. This discrepancy can lead to misaligned strategies and decision-making at the end to end process level, further compounding the challenges faced by the enterprise.

This comes to bear in the immense size of operations budgets. Software systems layered on top of each other are added for the sole purpose of making sure the Process is operating as intended. Examples are monitoring, execution reconciliation, coordination, process mining systems, that enterprises deploy alongside Processes. This is in addition to the large operations and technical maintenance teams constantly working to keep the Process operating.

II) Challenges with Buy and (re)align approach. The “Buy and (re)align” approach involves enterprises purchasing software solutions designed for a specific process after extensive due diligence. They then configure these solutions to meet their process requirements, integrate them into their existing systems landscape, and train their teams to use them.

However, several challenges arise. Firstly, enterprises must adjust their requirements to fit the capability of the solution. This often doesn’t happen entirely, leading teams to construct workarounds, “special cases”, and additions to the solution to meet their process requirements.

As new requirements emerge over time, these workarounds and special cases accumulate, creating a parallel set of sub-processes running alongside the solution. iii) This approach becomes resource-intensive and costly, as it requires maintaining and synchronising the main solution and the evolving sub-processes. If the solution lacks certain functionalities, teams start to develop “satellite” sub-processes off the main solution, further complicating the process landscape. 

iv) Additionally, the burden falls on large operations and technical maintenance teams to learn, maintain, and update a vast number of these specialized solutions across the enterprise. v) Most of these solutions are acquired with little consideration of other processes and solutions along the entire value chain, resulting in a collection of siloed externally provided solutions. This approach often leads to increased complexity, higher costs, and inefficiencies.

III) In addition to challenges posed by various development approaches, there’s a significant disconnect between business process operations, governance, and the technology and architecture designed to support them. This results in frequent changes and updates on both sides that aren’t effectively communicated or absorbed. Consequently, there’s often a disparity between “what is happening” operationally across the end-to-end process and “what we think is happening”.

This disconnect manifests in several ways. For instance, business operations and governance teams often have limited understanding of the technology and architecture underlying enterprise processes. Conversely, development teams may have only a high-level understanding of the processes they’re developing, focusing more on the abstract functionality of the software system.

Development and architecture teams are more focused on whether a specific API, microservice, database, or network connector fulfills its abstract purpose, rather than a focus on their role in the process or their impact on preceding or subsequent steps.

While this approach may be partially necessary, it creates a significant gap in process operations. This gap not only leads to substantial costs and resource consumption but also stifles innovation by keeping enterprises preoccupied with maintaining existing processes and fighting fires instead of building on them.

IV) In addition to all these, the enterprise maintains resource intensive and very expensive operations ecosystems. This includes internally developed bespoke Processes, purchased or licensed externally provided Process solutions, their connections, operations, integrations, interactions, as well as internally developed or purchased or licensed systems and solutions for monitoring, observing, reconciling, reporting and analysing all these systems.

Enterprise maintain resource intensive and very expensive operations ecosystems 

Enterprises cannot operate processes effectively

All this contributes to the large operations and technology budgets, and the large operations and technical teams and resources required to keep Processes operational, and non-standard operations within and across Processes. And worst, all this prevents enterprises from developing new products and services on top of a standardised operations layer.

About the author: Hossein Kakavand is the founder of Luther Systems and a passionate technologist. Luther Systems is a Deep Process Automation platform for automating complex enterprise processes. We are an early stage startup based in London and SF. We are developing a new category in automation of enterprise processes, and an opportunity to redefine the enterprise operations layer possibility to develop an unbounded number of new products and services with $100Bs in value.