21-07-2012, 10:54 AM
Process Modeling for E-Business
![Microsoft Word Document .doc](https://seminarproject.net/images/attachtypes/doc.gif)
Business Process Models
Before we can adequately discuss the pros and cons of various business process modeling methodologies, it will be helpful to discuss some generic attributes of business process models, as well as identify some of the features that one might like in a business process modeling methodology.
As mentioned above, business process models describe how a business works, or more specifically, how they accomplish missions, activities, or tasks (henceforth referred to as tasks). A single model shows how a business accomplished a single task. It would take many process models to fully detail the “hows” of most real world enterprises.
A single process can be quite involved. It can consist of many actors (people, organizations, systems) performing many tasks. In order to accomplish the overall task, the actors must complete specified sub-tasks in a coordinated manner. Sometimes, these sub-tasks can be performed in parallel. Sometimes they are sequential. Some processes require repetition of sub-tasks. Most processes have decision points where process flow can branch depending on either the condition of the system or the particular process execution. In cooperative processes actors must pass information. This information transfer can be the trigger for an actor to begin a sub-task. Other triggers are possible, such as time or interrupts. Some processes are ad-hoc. That is, the sub-tasks do not have well defined triggers. Actors may not need to complete all of a subtask before they or another actor start work on another dependent subtask. Finally, a process can look differently when described from the viewpoint of different actors. A business process modeling methodology needs to be able to represent these different aspects of a process description. A good methodology will present the representation in a manner that is easily transferred into the tacit knowledge of the viewer.
Process Modeling Benefits
There are many potential uses of process models [Browning 2002]:
(a) Program planning
(b) Baseline for continuous improvement
© Knowledge retention and learning
(d) Process visualization
(e) Training
(f) Framework for metrics
(g) Compliance, audit, and assessments
(h) Program execution
Even though there are many benefits to modeling business processes, it is rarely done, and when done at all, not done very well. Many companies have made efforts to document their processes, but very few have “built (and committed to improve and learn from) useful process models.” [ibid] The process models that do exist are often not well integrated and leave out key information that would fully describe the process. There is a need for better tools and techniques for modeling business processes and keeping them in synch with actual business activities.
Even when a project has a good, well-documented process, it is often too difficult to capture lessons learned from the on-going project and immediately update the process model. [Fagerstrom et al 2002] “Knowledge in the project is added as the project progresses. As a result, earlier-made decisions can be considered unreasonable at a later stage. It is important that the process supports exchange of design knowledge.” [ibid]
This is very true in conventional projects, but even more difficult to accomplish in web-based enterprises where the activities occur in “Internet” time and the activity interfaces often lie at the boundary between e-businesses. Since the e-business is more abstract than a conventional business, it is more difficult to do management by “walking around” (MBWA). Instead you will need a process model to do the “walking.” Later we will describe a Business Process Management System (BPMS) approach that will facilitate the MBWA technique of making a business better meet its goals and objectives.
Business Process Architecting
An architecture is the “arrangement of function and feature that achieves a given objective.” [Ring 2001] It is claimed that a business process must not merely be engineered, but should be “architected” given the very complex and fuzzy nature of business processes. [Biemans et al 2001] They go on further to say:
Engineers are trained to design systems such as bridges, computers, and aircraft in a well-structured manner. However, the design of business processes has not yet matured to this level. We argue that the complexity of business processes is the major cause…. Business process “architecting,” the high-level, functional design of business processes, is more an art than a science. [ibid]
They give several reasons for this extraordinary complexity of business processes:
(a) they involve several knowledge domains
(b) they operate on “vastly different” time scales
© they are often “nearly independent”
(d) people need years of training before they can understand them or “reason about them”
(e) a common “frame of reference” among the many stakeholders does not exist
(f) they have many “uncontrolled modifications”
Further complicating the problem is the fact that “business processes can change autonomously: The people that are part of a business process might modify this process, without any explicit design.” [ibid] In their paper, they give three elements needed for constructing business process models. First, we need a more on this later development strategy that “determines the order in which design steps are taken.” Second, we need mechanisms to “structure a model.” (Their paper is unclear on exactly what they mean by “mechanisms.” They make reference to “modeling styles” but this appears to be a non sequitur.) Third, we need a modeling language. The rest of their paper describes different techniques for developing the process model.
They describe three different modeling “strategies” that can be employed: process-oriented, resource-oriented, and data-oriented. Process-oriented strategy starts with the workflow of an organization (i.e., the behavior). The resources or “roles” within an organization are modeled first in the resource-oriented approach. The data-oriented strategy starts by first describing the data items that comprise the inputs and outputs of the business process. The paper does not suggest one strategy that is “best” but rather that the appropriate strategy will depend on the situation and often a hybrid strategy works well.
Modeling Criteria
Stefan Haberl has developed a set of seven criteria for evaluating process modeling methodologies [Haberl]:
• It must be able to model all the complexities of business processes listed above, to include:
Sequencing
Branching
Looping
Concurrency Constructs – fork and synchronize
Timeouts
Deadlines
Faults
Aggregation
• It must have a means of distinguishing roles and assigning them the various tasks.
• There must be an unambiguous graphical representation of the language.
• It must have a transaction model that allows for the description of how a process can be undone.
• It must specify how process instances will be triggered and identified throughout their execution
• It must have a means of specifying the characteristics of the business process that would be of interest to external users. This would include things like quality of service and pricing.
• The language should not mix in details of communications protocols.
The first three criteria are important for obtaining the first seven benefits identified by Browning. The second group of three is essential for automating process execution between cooperating, yet separate organizations. The last criterion keeps the process models at the right level of abstraction.
Business Process Modeling Methodologies
People have been modeling processes for many years. They have not always called their models “Business Process Models” because often, they were not describing what they thought of as business processes. That said, the techniques they used can and have been applied to describing “how” organizations perform their work. These models can be used to train new employees. They can be as aids in re-engineering processes. They can be used to develop simulations to test the processes on inputs that have not occurred in real life. Finally, they can be used to develop systems to automate the processes they model. In the last case, programmers may use the process model as a guide in developing the information system or more recently, some process models can be run though process execution engines that automate the process directly from the model.
In addition to having many uses, process models can be created or presented using many different methodologies. Each methodology has a different history. Many have a different way of looking at processes based upon the purpose they were originally created for. Some are more or less readable by nonprofessionals. Some are more or less useful for business process modeling.
The following is a brief description of some of the more prominent process modeling methodologies.
Process Modeling Methodologies
Flow Charts
Flow charts originated in, or were adopted very early by, the programming community. Programmers used them to describe the logic, or path of execution, within an executing program. Flow chart symbology and semantics is restricted to the limited number of atomic control structures available to programmers. Flow charts were developed to depict the path of execution within a single process. They do not have the expressive power to properly model groups of cooperating processes.