10 2 comments
Process, Rules, and Data – What more could you ask for?
A warm hello from the inubit Product Management team to our new colleagues at Bosch Software Innovations and our joint community! As the latest addition to the Bosch family, we are looking forward to contributing to new customer projects and the integration of the product lines.
In the last 12 years, inubit was involved in more than 450 successful BPM projects. Our lessons learned? BPM is no silver bullet, but it is a vital piece of the complex “enterprise application jigsaw”. Of course there are many other pieces to this jigsaw, including portals and Web 2.0 UIs, human workflows, EAI and SOA, complex decision making and data validation, data management, data analysis, application monitoring and operations support, to name but a few.
The combined Bosch Software Innovations and inubit product portfolio is adressing many of these requirements and provides customers with a platform for enterprise applications. Extensions like the distributed ESB for managing large numbers of distributed devices will make this platform a cloud based foundation for the Internet of Things and Services.
Challenges and Opportunities
This is not the first time in the software industry that a product portfolio is created through aquisitions. Consequently and rightfully, customers are asking themselves: How will the product lines grow together? How tightly will they be integrated? Can the additional complexity be managed? What are the benefits for us?
The integration of two complex product lines which have each been created over many years will take time and effort. However, the good news is that the two key products – inubit`s BPM Suite and VisualRules Suite – are already highly complementary. Even before the acquisition, the two companies have successfully worked together in various customer projects in diverse industries, ranging from banking and insurance (see HanseMerkur) to E-Mobility. The following illustrates the use of the two products based on a (simplified) example from the insurance industry.
Example: Claims processing with BPM and BRM
Claims processing is a fundamental cost driver for insurances. Firstly, processing the claim is costly because it involves expensive resources like subject matter experts. Secondly, the insurance has to ensure that only justified claims are reimbursed and fraud is prevented. Consequently, insurers are continually investing to optimize their claims processing processes.
Three key areas of an enterprise applications such as “claims processing” include process flow, decision making and data management. The interactions between these areas will be illustrated in the following.
Data Model: Both process flow and decision making require a data model upon which they operate. In our example, the (simplified) data model is shown in the lower left corner. A claim can contain multiple claim positions. The claim is also associated with an insurance contract, which contains a set of policies.
Decision Making: A key element of the claims processing is to decide whether a particular claim should be reimbursed or declined. Ideally, this decision should be made automatically. Consequently, a business rule is used to examine the claim. The rule shown in the lower right corner starts by checking whether the contract was already active at the time during which the event leading to the claim occurred. Next, the rule is iterating over all the claim positions, checking if each claim position is valid, and calculating the claim’s total amount. The latter can be checked with the maximum amount covered by the contract. As a result, the rule is returning the information whether the claim was valid or not.
Process Flow: We are assuming that an initial process (not shown here) is responsible for converting incoming postal letters into a structured, digital representation (usually involving scanning, OCR, indexing and data matching). Our process is triggered once the claim has been converted into this structured representation. The process starts with the event “New claim received”. The first task in our process is to start an “automatic claims analysis”. BPMN – the standardized Business Process Model and Notation used by the inubit Suite – is providing a specialized task type for decision making, which is used in our example. This task will invoke the appropriate rule in the Business Rules engine (lower right corner), e.g. via Web Services. The result of the rule execution is used to determine the next step in the process flow. If the claim is valid, the process continues with the task “Create payment instructions”. Otherwise, the process engine is creating a human user task. A subject matter expert will find this task in his task list in the corporate Intranet. The expert is analyzing the claim and making a decision. If he deems the claim to be valid, the process also continues with “Create payment instruction”. Leveraging the ESB capabilities of the inubit Suite, the next step is to send the payment instruction to the payment system, as shown in the process model.
Implementation: Since both products – process suite and rules suite – are inherently model driven, the actual application can be directly generated from the models shown in these diagrams. In the next blog entry from inubit’s Product Management team, my colleague Frank Puhlmann will provide a more in-depth description of the implementation details.
Of course, the integration of process, rules, and data as shown in this example is not all you could ask for. But it is an important first step and a key contribution to the “enterprise application jigsaw”. The example shows how the two products can already be combined today, bringing development efficiency, agility and IT/Business alignment to enterprise organizations. Over time, the benefits for our customers from an integrated BPM/BRM solution will increase even more.
We are curious to hear about your opinion. What would you wish for in the integrated product?