Process Modeling: Business Process Reengineering

   4. Business Process Reengineering :

Business process reengineering (BPR) is a management approach aiming at improvements by means of elevating efficiency and effectiveness of the processes that exist within and across organizations. The key to BPR is for organizations to look at their business processes from a “clean slate” perspective and determine how they can best construct these processes to improve how they conduct business.

 

Different definitions can be found. This section contains the definition provided in notable publications in the field.

 

Hammer and Champy (1993) define BPR as

 

    “… the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical contemporary measures of performance, such as cost, quality, service, and speed.”

 

Thomas H. Davenport (1993), another well-known BPR theorist, uses the term process innovation, which he says

 

    ”encompasses the envisioning of new work strategies, the actual process design activity, and the implementation of the change in all its complex technological, human, and organizational dimensions”.

 

Additionally, Davenport (ibid.) points out the major difference between BPR and other approaches to organization development (OD), especially the continuous improvement or TQM movement, when he states:

 

    “Today firms must seek not fractional, but multiplicative levels of improvement – 10x rather than 10%.”

 

Finally, Johansson et al. (1993) provide a description of BPR relative to other process-oriented views, such as Total Quality Management (TQM) and Just-in-time (JIT), and state:

 

    “Business Process Reengineering, although a close relative, seeks radical rather than merely continuous improvement. It escalates the efforts of JIT and TQM to make process orientation a strategic tool and a core competence of the organization. BPR concentrates on core business processes, and uses the specific techniques within the JIT and TQM ”toolboxes” as enablers, while broadening the process vision.”

 

4.1 Methodology :

 

Although the labels and steps differ slightly, the early methodologies that were rooted in IT-centric BPR solutions share many of the same basic principles and elements. The following outline is one such model, based on the PRLC (Process Reengineering Life Cycle) approach developed by Guha et.al. (1993).

 

   1. Envision new processes

         1. Secure management support

         2. Identify reengineering opportunities

         3. Identify enabling technologies

         4. Align with corporate strategy

   2. Initiating change

         1. Set up reengineering team

         2. Outline performance goals

   3. Process diagnosis

         1. Describe existing processes

         2. Uncover pathologies in existing processes

   4. Process redesign

         1. Develop alternative process scenarios

         2. Develop new process design

         3. Design HR architecture

         4. Select IT platform

         5. Develop overall blueprint and gather feedback

   5. Reconstruction

         1. Develop/install IT solution

         2. Establish process changes

   6. Process monitoring

         1. Performance measurement, including time, quality, cost, IT performance

         2. Link to continuous improvement

 

-> Loop-back to diagnosis

Process Modeling: VPML, BPMN, ARIS

3.1 VPML : Visual Process Modeling Language.

 

3.2 BPMN : The Business Process Modeling Notation (BPMN) is a standardized graphical notation for drawing business processes in a workflow. The primary goal of BPMN is to provide a standard notation that is readily understandable by all business stakeholders. These business stakeholders include the business analysts who create and refine the processes, the technical developers responsible for implementing the processes, and the business managers who monitor and manage the processes. Consequently BPMN is intended to serve as common language to bridge the communication gap that frequently occurs between business process design and implementation.

 

3.2.1 BPMN’S SCOPE:

BPMN will be constrained to support only the concepts of modeling that are applicable to business processes. This means that other types of modeling done by organizations for non-business purposes will be out of scope for BPMN. For example, the modeling of the following will not be a part of BPMN:

    * Organizational structures

    * Functional breakdowns

    * Data models

 

3.2.2 ELEMENTS:

 

The modeling in BPMN is made by simple diagrams with a small set of graphical elements. It should make it easy for business users as well as developers to understand the flow and the process. The four basic categories of elements are as follows:

 

    * Flow Objects

          o Events

          o Activities

          o Gateways

    * Connecting Objects

          o Sequence Flow

          o Message Flow

          o Association

    * Swimlanes

          o Pool

          o Lane

    * Artifacts

          o Data Objects

          o Group

          o Annotation

 

These four categories of elements give us the opportunity to make a simple diagram (BPD). It is also allowed in BPD to make your own type of a Flow Object or an Artifact to make the diagram more understandable. Many types of Diagrams can be created.

 

3.3 BPEL : is a language for specifying business process behavior based on Web Services. Processes in WS-BPEL export and import functionality by using Web Service interfaces exclusively. WS-BPEL provides a language for the specification of Executable and Abstract business processes. By doing so, it extends the Web Services interaction model and enables it to support business transactions. WS-BPEL defines an interoperable integration model that should facilitate the expansion of automated process integration in both the intra-corporate and the business-to-business spaces.

 

In addition to providing facilities to enable sending and receiving messages, the BPEL programming language also supports:

 

    * A property-based message correlation mechanism

    * XML and WSDL typed variables

    * An extensible language plug-in model to allow writing expressions and queries in multiple languages: BPEL supports XPath 1.0 by default

    * Structured-programming constructs including if-then-elseif-else, while, sequence (to enable executing commands in order) and flow (to enable executing commands in parallel)

    * A scoping system to allow the encapsulation of logic with local variables, fault-handlers, compensation-handlers and event-handlers

    * Serialized scopes to control concurrent access to variables

 

3.3.1 BPEL Design Goals

 

There were ten original design goals associated with BPEL:

 

   1. Define business processes that interact with external entities through Web Service operations defined using WSDL 1.1, and that manifest themselves as Web services defined using WSDL 1.1. The interactions are “abstract” in the sense that the dependence is on portType definitions, not on port definitions.

   2. Define business processes using an XML-based language. Do not define a graphical representation of processes or provide any particular design methodology for processes.

   3. Define a set of Web service orchestration concepts that are meant to be used by both the external (abstract) and internal (executable) views of a business process. Such a business process defines the behavior of a single autonomous entity, typically operating in interaction with other similar peer entities. It is recognized that each usage pattern (i.e. abstract view and executable view) will require a few specialized extensions, but these extensions are to be kept to a minimum and tested against requirements such as import/export and conformance checking that link the two usage patterns.

   4. Provide both hierarchical and graph-like control regimes, and allow their use to be blended as seamlessly as possible. This should reduce the fragmentation of the process modeling space.

   5. Provide data manipulation functions for the simple manipulation of data needed to define process data and control flow.

   6. Support an identification mechanism for process instances that allows the definition of instance identifiers at the application message level. Instance identifiers should be defined by partners and may change.

   7. Support the implicit creation and termination of process instances as the basic lifecycle mechanism. Advanced lifecycle operations such as “suspend” and “resume” may be added in future releases for enhanced lifecycle management.

   8. Define a long-running transaction model that is based on proven techniques like compensation actions and scoping to support failure recovery for parts of long-running business processes.

   9. Use Web Services as the model for process decomposition and assembly.

  10. Build on Web services standards (approved and proposed) as much as possible in a composable and modular manner.

 

BPEL is an Orchestration language, not a choreography language . The primary difference between orchestration and choreography is executability and control. An orchestration specifies an executable process that involves message exchanges with other systems, such that the message exchange sequences are controlled by the orchestration designer. A choreography specifies a protocol for peer-to-peer interactions, defining, e.g., the legal sequences of messages exchanged with the purpose of guaranteeing interoperability. Such a protocol is not directly executable, as it allows many different realizations (processes that comply with it). A choreography can be realized by writing an orchestration (e.g. in the form of a BPEL process) for each peer involved in it. The orchestration and the choreography distinctions are based on analogies: orchestration refers to the central control (by the conductor) of the behavior of a distributed system (the orchestra consisting of many players), while choreography refers to a distributed system (the dancing team) without centralized control.

Process Modeling: Definition

   Process Modeling :

The term process model is used in different contexts. For example, in Business process modeling the enterprise process model is often referred to as the business process model. Process models are core concepts in the discipline of Process Engineering.

Process models are processes of the same nature that are classified together into a model. Thus, a process model is a description of a process at the type level. Since the process model is at the type level, a process is an instantiation of it. The same process model is used repeatedly for the development of many applications and thus, has many instantiations. One possible use of a process model is to prescribe how things must/should/could be done in contrast to the process itself which is really what happens. A process model is roughly an anticipation of what the process will look like. What the process shall be will be determined during actual system development.

 

The goals of a process model are to be:

 

Descriptive :

                o Track what actually happens during a process.

o Takes the point of view of an external observer who looks at the way a process has been performed and determines the improvements that have to be made to make it perform more effectively or efficiently.

Prescriptive :

                 o Defines the desired processes and how they should/could/might be performed.

                 o Lays down rules, guidelines, and behavior patterns which, if followed, would lead to the desired process performance. They can range from strict enforcement to flexible guidance. Explanatory :

                 o Provides explanations about the rationale of processes.

                 o Explore and evaluate the several possible courses of action based on rational arguments.

 o Establish an explicit link between processes and the requirements that the model needs to fulfill.

                 o Pre-defines points at which data can be extracted for reporting purposes.

 

Meta-process modeling is a type of metamodeling used in software engineering and systems engineering for the analysis and construction of models applicable and useful some predefined problems. Meta-process support the effort of creating flexible process models. The purpose of process models is to document and communicate processes and to enhance the reuse of processes. Thus, processes can be better taught and executed. Results of using meta-process models are an increased productivity of process engineers and an improved quality of the models they produce.

 

Business process management (BPM) is a method of efficiently aligning an organization with the wants and needs of clients. It is a holistic management approach that promotes business effectiveness and efficiency while striving for innovation, flexibility and integration with technology. As organizations strive for attainment of their objectives, BPM attempts to continuously improve processes – the process to define, measure and improve your processes – a ‘process optimization’ process. Business process management life-cycle : Design, Modeling, Execution, Monitoring, Optimization.