The present invention relates to process models, and, more specifically, to changes of business process models.
Business transformation deals with the strategic alignment of business and information technology (IT) to deliver enduring on-demand value of continual business innovation and improvement. Business transformation comprises three main challenges: (1) analysis and modeling of business strategy and operations to drive business transformation; (2) efficient generation of an IT solution from a business model using techniques from Model-Driven Development (MDD) of software systems; and (3) monitoring and dynamic management of business performance for continual improvement.
When dealing with business process models, one often gets into a process merging scenario where two or more process models have to be brought together in order to create an improved business process. One scenario for process merging is the improvement of an existing process model (AS-IS model) by a reference model where some parts of the existing model are preserved and others are replaced. Process merging is also required when companies become subject to acquisitions and mergers. In such situations, processes need to be aligned at the business and IT level. However, differences also have to be identified and preserved, if appropriate. A third scenario arises if two or more different versions of the same process model need to be integrated.
Existing solutions and tools do not offer support for iterative merging of business process models. In particular, they do not deal with the problem of process merging in the situation where two versions of a process model are derived from a common source model and these two versions have to be consolidated. In such a scenario, conflicts and dependencies between change operations need to be computed, visualized and resolved.
Further, version management of models is important for enabling modeling in distributed modeling scenarios. In general, it requires the computing and visualizing of changes that have been performed on a common source model while creating different versions. Based on this, version management capabilities then have to enable the user to create a consolidated model, by accepting or rejecting changes and thereby modifying the original source model.
A requirement for consolidation of changed models is that it should impose minimal manual overhead on the user. Otherwise, a straightforward solution is that the user remodels all changes manually. Nowadays, version management is a common functionality of mainstream modeling tools such as the IBM Rational Software Architect. However, for behavioral models such as process models, inspecting and accepting or rejecting changes can involve relatively large overhead if the changes to be dealt with are numerous. One reason for this is that the semantics of behavioral models are usually more complex than for structural models. A straightforward approach to compute all changes on model elements (called elementary changes) and display them is difficult to handle for the user. Typically, elementary changes cannot be considered in isolation but must be aggregated to compound changes.
Informally, if two changes are dependent, then the second one requires the application of the first one. If two changes are in conflict, then only one of the two can be applied. Other than in structural models, in behavioral models changes are often dependent on one another. As a consequence, an approach for computing dependent and conflicting changes is required. Further, once conflicts have been computed, techniques for resolving conflicts are needed that take into account the characteristics of the modeling language. For example, conflicts in process models are resolved differently from conflicts in state chart diagrams.
USPTO Backgrounds
USPTO Backgrounds