Companies are finding many reasons to capture their business processes. Companies who have merged want to examine processes across their lines of business to discover which one is the best of breed. Other companies are looking to improve their existing processes, or even to automate them. In some countries, government regulations require that business processes be properly documented. For example, the Sarbanes-Oxley act in the United States regulates that certain processes must be well documented. These are among the many drivers in the business world today that are making companies take a closer look at their processes.
In general, business process drivers can be summarized into three major categories:
- Documentation. Companies need to capture business processes so that others can understand how they work, who is involved, and how activities flow from beginning to end. Typically a business analyst who understands how the processes work models these processes.
- Redesign. Many businesses want to improve their business processes to reduce inefficiencies, drive down costs, and respond faster to customer requests. A process cannot be redesigned before it is understood, so it must first be captured. Redesign can only come after you have properly documented the process. Typically a technical analyst, or perhaps an I/T liaison to the business who understands both the business needs, and the I/T systems models these processes.
- Execution. In most cases, the best way to improve the efficiency of a business process is to apply automation to it. If you can reduce or eliminate manual work, the process can be performed faster and at a lower cost. To apply process automation, the businessâs I/T staff or a consultant must write code or use a middleware product. It would not be advisable to automate an inefficient process. For this reason, this phase should only occur after you have redesigned the process.
Other types of modeling are out of the scope of this article, for example UML modeling performed by a software architect as part of the code development cycle, or enterprise modeling used in impact analysis. This article focuses on business modeling, and you only need conceptual product knowledge.
To capture any business process, no matter what the goal, you need to use a tool. In general, the three most common tools are:
- Text-based document. You could use a word processor such as IBM Lotus® Word Pro to create a document containing information about the process.
- Drawing tool. You could use a graphic tool such as IBM Lotus Freelance Graphics to create pictures to represent the process flow. Typically the picture is combined with a text document that contains further details.
- Business modeling tool. You could use a tool such as WebSphere Business Modeler to create a model of the business process. A model is graphic in nature, yet it is far more than just a picture.
This article examines the usage of these tools across the three business reasons for capturing the business process.
Text based documents
One of the simplest tools to document a process is a text-based document processor. Text documents have been used for many years to capture business processes. Their advantage is that virtually every business already has a word processing tool.
- Some concepts are difficult to express with just words. For example, in a complex flow where there are nested subprocesses, or branching decisions with six different outputs, it can be difficult to understand the process flow if it is just described with words. A picture can express these concepts more easily, while words alone cause confusion. Multinational corporations face language barriers when using just text for documentation.
- Text is good at expressing what is done in a single step of in a business process. However, the overall end-to-end scenario can be difficult to envision.
- If you change the process, it is difficult to determine all of the places in the document that need to be updated. For example, if three steps are to be combined into a subprocess, and reused again later in the high level process, itâs very difficult to know all of the places where text needs to be altered. This means that the document would become less accurate over time, as the process changes.
- Only one person at a time can work on a document, because it is just a simple file. Collaborative development is not possible.
- Other than documenting what the business process actually is, a text based document does nothing to aid in the redesign of a process.
- I/T uses a technical tool set to build the automated business process. Everything the analyst documented must by re-entered into the technical tool set. This can take a considerable amount of time.
- Business analysts and I/T professionals have different semantics and different ways to express concepts. What seems clear and concise to an analyst might be ambiguous to an I/T resource.
Text-based documents recommendation
Use a text-based tool to document use cases, but not the overall business process. Even when documenting use cases, tools such as IBM Rational® ClearCase offer many advantages over a plain text document. A document processor is not the optimal tool for capturing a business process.
Businesses have used flowcharts and other graphics for years for one simple reason: a picture can often express something quickly and simply, which would take thousands of words in a document. A flowchart is good at showing the big picture, instead of bogging you down in the details like a text document can.
- A flowchart picture is just a picture. It alone cannot describe the details behind each step in a process. The drawing spaces just doesnât provide enough room to include every detail. A separate text document is required as well, to hold the details missing from the picture. Now you must keep the picture and the document in sync whenever a change is made to either one. This is not a trivial task, especially for a large complex process.
- The flowchart, being a drawing, is very static. You cannot look at different aspects of it. For example, you cannot click a button to show the flow by organization or by role. What you see is what you get; it is just a picture.
- Most drawing tools have a large library of shapes and graphic icons that you can use in the picture. This allows flexibility, but it also means that it is very easy to create a picture that is ambiguous. A circle can be used as a decision, or a diamond, or a square, or any shape for that matter. When someone other than the author examines the picture, there is an opportunity for miscommunication.
- If an organization sets standards for which shapes are to represent different objects in a process, there is no way to error check to be sure that the shapes are used correctly. It is up to each author to enforce the rules.
- Only one person at a time can work on a drawing, because it is editing a simple document. Collaborative development is not possible.
- A simple picture cannot represent any of the dynamic aspects of a business process. For this reason, other than documentation, a drawing tool does nothing to aid in the redesign of a business process.
- I/T would still need to reenter all of the information from the flowchart as well as the accompanying text document into their own tool set. Pictures alone cannot produce useful I/T artifacts. This manual work takes considerable time, with ample chance for miscommunication.
- I/T could build something that does not match the expectations of the business users, which could lead to costly iterations reworking the code until they meet the expectations of the business.
- A drawing tool does not help drive reuse. It cannot consume Web Service Definition Language (WSDL), XML Schema Definition (XSD) or other standards-based artifacts. A drawing tool cannot query a registry, such as IBM WebSphere Services Registry & Repository, to see if a reusable service already exists. All of this work is left to I/T, adding time to the development cycle.
Drawing tool recommendation
Drawing tools alone cannot express a business process. To capture the details you to use them along with a word processing tool. In addition, the two documents must be kept in sync. Together they work better than either one does alone, but they still fall short of being an optimal solution for any of the three business drivers for capturing a process.
Business Modeling tool
Using a modeling tool such as WebSphere Business Modeler has all of the advantages of a flowchart picture, since it includes a visual representation of the process. However, it also has the advantages of a text document, since each object in the model can include attributes like comments and documentation.
- Like a drawing tool, a model presents a visual image of the business process. But it is more than just a picture: each of the elements in a model has attributes you can use for documentation. It combines both the visual and textual aspects of the process in one single entity: the model.
- A model is more than just a picture. The view on the screen is just one aspect of the model. For example you can switch from a free-form flowchart to a swimlane (line of visibility) view at any time.
- A modeling tool such uses a consistent set of objects to represent the business process. For example, a decision is always a diamond. The model precisely represents vital aspects of the business process.
- A modeling tool can import standards-based artifacts such as XSD and WSDL, or search for them in a registry. This not only means it can help encourage reuse of existing assets, but I/T does not have to re-enter or recreate information, saving time and ensuring accuracy.
- Many business modeling tools enable you to simulate a process model -- something which could never be done with just a simple picture! Simulation enables the user to understand the dynamic behavior of the business process. Where are the times in the process? Where are the costs? Where are the bottlenecks? Are there resource shortages? These questions help in the effort to redesign the business process.
- When a process has been redesigned, it too can be simulated. The as-is (current state) process can be compared with the to-be (future state) process, to verify the impact of the process redesign.
- These capabilities enable a business to perform the redesign themselves, rather than having to hire expensive consultants.
- Business modeling tools can transform the business model into useful artifacts for I/T. This reduces or eliminates the need for I/T to re-enter information into their technical tool set. The artifacts themselves are usually based on runtime standards such as WS-BPEL.
It could be argued that modeling for execution can be performed by a technical tool designed for the runtime environment, such as using WebSphere Integration Developer to create WS-BPEL. There are several disadvantages to creating the technical WS-BPEL model directly, without first using a business modeling tool:
- Technical modeling tools cannot perform simulations to ensure that the process is efficient before it is deployed.
- Using a technical modeling tool without a business modeling tool means that I/T needs to create a model from scratch, based on drawings or paper documents. As previously discussed, this can lead to miscommunication and tends to slow down the development cycle.
For these reasons, modeling for execution is best performed with a business modeling tool before working with a technical modeling tool.
Modeling tool recommendation
These capabilities of modeling tools go well beyond anything you could do with a simple drawing tool and/or a word processing tool. The process can be captured in greater detail, with a higher degree of accuracy. Reuse of existing resources is encouraged. Simulation enables process redesign, and useful artifacts can be generated for I/T developers. A picture is just a picture, but a model is a plan for how to build something.
These capabilities make Business Modeler an ideal tool, whether the goal is modeling for documentation, redesign, or execution.
WebSphere Business Modeler as a business modeling tool
A business modeling tool is clearly the best solution. WebSphere Business Modeler is an industry-leading tool in the business modeling space. For all three of the reasons for modeling, Business Modeler has many useful features and functions.
In addition to the basic documentation capabilities of any modeling tool, Business Modeler has these additional capabilities:
- A non-technical business analyst does not want to see the technical details in a model. An I/T resource does want to see them. Business Modeler has different modes to enable this: basic, intermediate, advanced, and WebSphere Process Server. The more technical users can view technical attributes that are hidden from the business user. Yet they are still part of the model, even if the business user cannot view them.
- Swimlanes in Business Modeler can be based on more than just job role. You can also use individual resource definition, bulk resource definition, classifier, organization unit, or location. You can create your own classifiers, which enables you to organize your swimlanes based on any attribute you may define.
- Business Modeler uses a model instead of a simple drawing file. This allows multiple users to collaborate, using a repository such as IBM Rational ClearCase for check-in/check-out, version control, and locking resources.
- Business Modeler can publish models using IBM WebSphere Publishing Server, so that authorized users can view the model using just a Web browser. Users can also offer comments and feedback. This enables a broader spectrum of users in a business to collaborate and offer their input on the process being modeled, which helps ensure that it is correct and complete.
- Business Modeler captures more than just the process itself. It can capture information on organizations, roles, resources, qualifications, and more. These aspects of the business process are vital for the understanding of the environment in which the process runs.
- Business Modeler can generate reports on the static parts of the business process, or produce queries across the entire process catalog.
- The simulation engine in Business Modeler includes many advanced features that enable you to accurately simulation your process. If a simulation is not accurate, the generated reports are also not accurate, or useful. To more accurately simulate real-workd process behavior, you can use distributions, steady state simulation, business item instances and other capabilities.
- Dynamic analysis in Business Modeler includes many reports, which enable you to understand the results of the simulation. You can also create your own custom reports, if there is something you want to show that is not in any of the standard reports. You can also export report results to delimited files for further offline analysis.
- When the redesign of the process has been proven out through simulation, I/T can add additional technical details to the model. You can then export the model, creating useful artifacts for I/T using standards such as WS-BPEL, XSD and WSDL.
- You can also reuse the business model in IBM Rational Software Architect, enabling the software architects to create UML models based on the information captured by the business analysts.
- The technology modes of Business Modeler perform deeper error checking on the model. For example, WebSphere Process Server mode checks the model to ensure that the generated WS-BPEL will be correct.
The following cases are examples of the ambiguity of a drawing tool versus the precision of a modeling tool. In each case, something that could be left open to interpretation from a drawing is better defined in a model.
Our first case (Figure 1) shows how a drawing tool typically handles flow diagrams, which can be very ambiguous. Does the flow from
review request go into one of the following steps? Does it flow into both steps in parallel? The drawing tool does not give enough information to know this.
Figure 1. Ambiguous flow drawing
Compare Figure 1 with Figure 2. Business Modeler uses a fork to clearly indicate that the two steps are performed in parallel. The model is unambiguous, while the picture in Figure 1 is open to interpretation.
Figure 2. Unambiguous Flow model
No indication of flow direction
Figure 3 shows a common diagram style with no indication of the flow direction. Does the flow being with
verify address? Does the flow being with
verify part numbers? It all depends on the interpretation of the person viewing the picture.
Figure 3. Flow direction drawing
Compare Figure 3 with Figure 4. Connectors in Business Modeler always show the direction of the flow. There can be no question as to which task is first.
Figure 4. Flow direction model
Inconsistent use of shapes
Figure 5 uses a circle as a decision point, as well as a diamond. Another viewer might interpret the circle as a node for a parallel branch. There is no way in a drawing tool to enforce the proper usage of the different shapes.
Figure 5. Inconsistent shapes in a drawing
In Business Modeler, a decision is always a diamond. The process model enforces consistency. Note that the merge activity brings the two paths down into one single path. Decisions also show information as to how often the business analyst thinks each branch will be taken.
Figure 6. Consistent shapes in a model
Figure 7 shows confusing graphics from a drawing tool. What does the stick figure man in the diagram represent? In addition, for multinational corporations, a graphic figure might mean different things to different cultures.
Figure 7. Ambiguous graphics in a drawing
In Business Modeler, you use swimlanes to indicate the resources required for each step, as Figure 8 shows. Rather than using the stick figure, it is clear now that the
verify address step is performed by a person with the role of
Figure 8. Swimlanes clarify required resources
As an alternative, you can add labels to tasks, displaying the role information, as in Figure 9:
Figure 9. Task labels in the model
Because of the need to tie the picture from a drawing tool to a document with the details in text form, it is common to use numbers for each step. Over time as the process is updated, numbering could become confusing, for example:
- The process in Figure 10 originally had steps 1.0, 1.1, 1.2 and 1.3.
- At a later time, a subprocess step was added between 1.1 and 1.2, labeled 1.11
- At an even later time, step 1.2 was eliminated.
Now the process flow looks as if it could be missing a step. If a step needs to be added between 1.1 and 1.11, the resulting number could further add to the confusion.
Number references in a drawing
In Business Modeler, each of the objects in the process has attributes to describe it, so thereâs no need to maintain an external document for the step. Without the need for the external document, you no longer need numbers for the steps.
Business Modeler uses a different icon to show that
update request is a subprocess, whereas the drawing tool allowed a rectangle to be used for both the subprocess and a task. Lastly, the business model also shows the flow of data, which is missing from the drawing.
Figure 10. Number references in a model
References to other processes
In a drawing tool, when you refer to a different process you have to describe it in words, as Figure 11 shows:
Figure 11. Textual references to other processes in a drawing
In Business Modeler, you can right-click the global process then select Launch Global Process Editor to automatically open the process, as Figure 12 shows. The user does not have to track down the additional documentation. The process model has a link to the global process. This makes management of the model far easier than managing a set of pictures.
Figure 12. Automatic process links in a model
Lack of error checking
In a drawing tool, there is no error checking or enforcement of rules. Figure 13 shows a process with a yes/no decision, but no output condition for a ânoâ decision.
Figure 13. No error checking in a drawing
In Business Modeler, I/T can use technology modes such as WebSphere Process Server mode. It flags errors ranging from unconnected links, to undefined conditions or other missing attributes. This ensures that the model will be complete and correct.
Figure 14. Error checking in a model
Often times the domain expert who creates a drawing knows their area. To such an expert, the drawing is clear and complete. To another person without the domain knowledge, the drawing might seem confusing or ambiguous.
Figure 15. Ambiguous logic in a drawing
Business Modeler clearly shows each of the paths and the logic. The model is clear and unambiguous, even to someone who is not a domain expert.
Figure 16. Unambiguous logic in a model
This article showed why modeling is important to a business, and how WebSphere Business Modeler can help whether modeling for documentation, redesign or execution.
- Using Loops in WebSphere Business Modeler v6 to improve simulations and export to BPEL (developerWorks, March 2007)
- Process anti-patterns: How to avoid the common traps of business process modeling, Part 1 (developerWorks, February 2007)
- Business Process Execution Language for Web Services version 1.1 (developerWorks, February 2007)
- Transforming models from WebSphere Business Modeler to WebSphere Integration Developer (developerWorks, May 2005)
- Using WebSphere Business Modeler, Monitor, and Process Server for BPM (WB170 or VB170)
- WebSphere Business Modeler: Process Mapping, Simulation, and Analysis (WB182 or VB182)
- WebSphere Business Modeler: Process Mapping and Analysis (BI184 or VB184)
- Designing for Performance Measurement Using WebSphere Business Monitor (WB189 or VB189)
- WebSphere Business Modeler information
- WebSphere Integration Developer information
- Redbook: Business Process Management: Modeling through Monitoring Using WebSphere V6 Products
- Redbook: Best Practices for Using WebSphere Business Modeler and Monitor
- Redbooks: Patterns: SOA Foundation - Business Process Management Scenario
- IBM Modeler User's Group (IMUG)
- Sharing business processes in a team environment using WebSphere Business Modeler and CVS (developerWorks, February 2007)
- developerWorks WebSphere development tools
- developerWorks Websphere business integration
- developerWorks Rational ClearCase