The Insurer operates the Supplier Claims Order Fulfillment process, as part of the claims value chain. This process operates across 6 teams & 12 software systems. To operate the process end-to-end, each function performs the same cycle of steps i) send data & info to the System, ii) receive response from System, iii) compute & validate response, iv) share & store execution of step, v) evaluate & initiate next step. For reliable operations, all teams & systems involved should operate the same end-to-end Process. They often don’t!  This leads to operational & technical challenges, which make process operations unreliable. The opportunity is providing a platform to reliably operate the end-to-end process, across all teams & systems involved.

Traditional solutions to end-to-end process operations are unreliable & expensive. Enterprise Operations are generally function-first, they continue to improve functions & systems. Processes are considered secondary. The thinking is that if we have great functions & systems, the business can operate any process! Luther's platform is designed process-first, & primarily focuses on end-to-end processes.  Reliable end-to-end process operations include consistent operation, and great functions & systems. Traditionally enterprises use bespoke connectors & local operations scripts for process operations, which are fragmented, siloed, and change separately, and so are ineffective for reliable process operations. To remedy this, enterprises use automation tools. However they are ineffective at end-to-end process operations, due to their limited scope and scale, and stitching them together also doesn’t solve the problem.

Luther’s unique value for reliable end-to-end Process Operations is providing i) standard connectivity & ii) a common operations script, across all teams & software systems. Luther’s platform vertically integrates i) distributed system technology ii) optimal resource allocation & management, iii) real time event ordering & streaming, iv) deterministic event processing & execution, for reliable end-to-end process operations. Luther’s platform does this by i) connecting systems to standard platform nodes, rather than to each other, and ii) teams & systems can change the common operations script but all teams & systems have to know & agree to the change, so all teams & systems involved operate the same end-to-end Process all the time!

To implement the platform, i) Luther’s team mapped the Process, ii) Identified teams & software systems in the process, iii) allocated nodes (servers) to teams, iv) connected nodes to systems, v) set up the Platform on the nodes. vi) the Insurer’s team along with Luther’s team developed the  Common Operations Script (code) for Process Operations, vii) the process went Live. Beyond the commercial results, this led to operational benefits in production, i) reliable operations across the process & over time, ii) Execution visibility, iii) reduction of reconciliation, iv) 5X smaller Ops teams, v) enforced compliance checks. Also, technical benefits during development, i) automated infrastructure., connectors and development environment setup, ii) focus only on development of process operations rather than technical setup and infrastructure, iii) consistent real time updates, iv) eliminate DevOps teams, v) 5X smaller Dev teams.

Ultimately, this leads to reliable end-to-end process operations!

The Supplier Claims Order Fulfilment process has these steps: i) Policy holder notifies Insurer of an incident,  ii) Insurer acknowledges claim and verifies claimant policy, iii) Insurer’s Claims Handling team sends claimant list of suppliers, iv) Claimant goes to a supplier, v) Supplier provides an assessment to Insurer, vi) Insurer’s Supplier Assessment team requests clarifications, supplier responds, vii) Insurer’s Supplier Management team approves work, viii) Supplier’s Finance team sends an invoice to Insurer on completion, ix) Insurer’s Supplier Management team validate invoice, x) Insurer’s Payment team make payment to supplier & claim is closed.

Process Operations

Different teams have different operations, rules and governance and they also utilize and operate a variety of  software systems in different ways. Each system operates a specific function for the process. To operate the process end to end, each function performs the same cycle of steps: i) send data & information to the System, ii) receive response from the System, iii) compute & validate response, iv) share & store execution of step, v) evaluate & initiate next steps.

Specifically, operating processes across fragmented and siloed teams and software systems affect process operations both technically during the development phase & operationally once they go live in production.

The teams in Insurer’s supplier claims order fulfillment process (Claims, Supplier, Finance, and Payments) are large and disjointed, and operate separately. This often leads to inefficient operations, incomplete or submitted requests or payments, payment backlogs, delays and data errors. This results in high operational costs and longer processing times. Inefficiencies and slow payment times reduce satisfaction for customers and suppliers, and Insurer risks penalties for delayed payments.

To operate an end to end process enterprises traditionally set up projects, with i) dedicated  large teams,  & ii) infrastructure set up, to iii) develop application (end to end process) code, & iv) set up maintenance systems. This bespoke approach results in high operations cost & multiple technical & operational problems.

Bespoke connectors and local operations scripts & why they are unreliable

Traditional solutions for operating enterprise processes are inefficient. They have disjointed local operations that are modified and maintained by teams that own specific parts of the process. As the process changes and evolves, local operations are often modified without fully considering its impact on the rest of the end to end process operations. They also deploy local and non-standard connectors between teams directly interacting with each other in the process. For more details please visit Project Ford Full Case Study

Automation tools & why stitching them together is unreliable

To attempt to remedy the inefficiencies of this approach, enterprises use automation tools such as RPA and workflow automation tools to operate the process. These tools are effective at operating local task and workflow operations, usually for 1-2 teams but do not scale to end-to-end process operations across multiple teams and software systems. This approach does not solve the problems of operational friction, inefficiencies, delays and errors. For more details please visit Project Ford Full Case Study

Implementation

Project Ford is a product built on the Luther platform using Deep Process Automation Technology to automate the process of claims fulfillment with suppliers. The implementation steps included:

• Process Mapping: Luther’s team worked with Insurer teams to map the process operations.
• Identify Software Systems: Luther's team identified systems involved in the process operations.
• Assigning Nodes: Luther's team allocated dedicated (server) nodes to each team in the process
• Connectors to Software Systems: For each team, the platform connects its node to its systems
• Platform Set-up: Luther's team deployed the platform on all nodes.
• Common Operations Script for Process Operations: The Insurer development team, in collaboration with Luther, developed the application code  to operate the end-to-end process.
• Go Live (Production)

Luther, working with Insurer’s teams, mapped the process in 4 weeks & set up Platform in 1 day. Insurer’s team then worked with Luther’s team to develop process ops into a Common Operations Script in 8 weeks.

How it all comes together reliably, with the Luther Platform

Luther’s platform reliably operates the end-to-end supplier claims fulfillment process by providing a standard connectivity and common operations scripts.

Operational and Technical Results

The Luther Platform streamlines operations across enterprise processes, reducing process time and cost while maintaining transparency and flexibility.

Luther platform Links

Find more information about Luther’s Platform Core Features here.

For a more detailed introduction to the Luther platform please visit Luther Deep Process Automation Primer

For a detailed introduction and documentation examples please see the Luther Platform website.

For more information about Luther’s platform please visit Luther Systems website.