Diagramming Business Processes

Note This section is adapted from Appendix K of my book, Effective Software Project Management (Wiley, 2006). Often, you will choose to start identifying requirements for the project by mapping the current business process (the As Is process) or processes that are going to be affected. You might also want to map the business process after the solution is installed (the To Be process). Both of these are excellent artifacts to use as input to the requirements gathering process. From the business process development perspective, gathering requirements often begins with knowledge of the current or As Is business process and ends with the To Be business process. The gap between the As Is and To Be processes is filled with new or enhanced project deliverables. Having the As Is and the To Be business process flow diagrams is an invaluable aid in the ensuing solutions development effort. It is an ongoing dictum of today's business that you must continuously improve your business processes. The old If it ain't broke, don't fix it adage no longer applies. If you aren't improving your processes and the way that they support your clients, you run the risk of losing market share. Your client should also be taking the lead in approaching your teams to demand process improvement. Conversely, they are your clients, and you should be ever watchful for ways to improve the service that your clients provide to their clients. All organizations are under pressure to improve. The pressure can come from their clients, the competition, environmental changes, or a combination of the three. The improvements can be in their products or their processes. All too often, the client doesn't give their business to the company with the best product. When clients find that a supplier is too difficult to deal with, they will decide to use a second best supplier who is easier to deal with. This also applies to internal organizations. One reason for outsourcing is a belief (frequently inaccurate) that other groups will be easier, faster, or cheaper to deal with. Internal organizations need to counter this belief by clearly demonstrating that they are continuously improving what they can deliver and their methods of delivery.

What Is a Business Process?

A business process is a collection of activities that takes one or more kinds of input from one or more different sources and produces value for the client (see Figure 3.4). The focus of the business must be to ensure that the effort of dealing with the process does not outweigh the value received from completing the process.

Figure 3.4: A business process Order entry and fulfillment is a clear example of a business process. From the client's viewpoint, the process starts when the client places an order; it ends when the client receives the goods requested. There are numerous activities in between. Credit checks may be run to confirm that the client can pay for the order. Inventory is assessed to confirm you have what the client is requesting. A typical list of activities would include the following:
y y y y y y y y y y

Receiving the order Logging the order Verification of completeness Client credit check Determining the price Inventory checking Production request Order picking Order packaging Shipment

You will notice that the activity in a high level business process may include activities that can be regarded as processes in and of themselves. Processes can be decomposed into other processes until you reach the task level where some interim component is produced. The key is to start with the client as the focus of the original process and then define the sub processes by their contribution to added value.

Creating a Business Process Diagram

How do you diagrammatically represent a business process? You can use the standard flowchart to keep it simple and couched in symbols you are already familiar with. Figure 3.5 shows the more commonly used symbols.

Figure 3.5: Standard flow chart symbols The symbols shown in the figure denote the following process steps:
y y y

y y y

y y y y

Operation: Denotes that a change has taken place. The input is somehow changed as a result of having gone through this process. Movement: Denotes the movement of output from one process step to become the input to the next process step. Decision: Denotes that a question needs to be answered. There are two flow paths that emanate from a decision box: Yes or True and No or False. You follow one of these paths based on the decision. Inspection: Someone other than the person producing the output must inspect it for quality, conformance, or some other tangible characteristic. Often an approval is included as a successful inspection. Document: Denotes a paper document. Delay: Denotes a wait state in a process. It's usually associated with something joining a queue and waiting for the operator of the next process step to become available. Storage: Indicates that an item has been placed in storage and must wait for a release before moving to the next process step. This usually represents wasted time that must be removed from a process. Annotation: Provides added detail about some process, which is needed for clarification. It might also include the position title of the person responsible for the process. Direction of Flow: Denotes the order of process steps. Transmission: The interrupted arrow indicates when information is to be transmitted from one physical or virtual location to another. Connector: Connects the flow between two separate locations; often used as an off page connector. Boundaries: Denotes the initiating and closing processes of a flow diagram. Usually the words START or BEGIN are associated with the initiating process, and STOP or END with the closing process.

Business Process Diagram Formats

Three common formats are used to render business process diagrams. The first (shown in Figure 3.6) is the top down and left to right format. It is commonly used in program and system flow charts. The second is the swim lane format (shown in Figure 3.7). It identifies the actors who participate in the business process.

Figure 3.6: The top down, left to right format

Figure 3.7: The swim lane format Software developers are typically most familiar with the top down, left to right format. It harkens back to the early days of programming and is the standard they adopted several decades ago. It follows the logical thought patterns of software developers and is therefore their popular choice. However, I prefer the swim lane format when diagramming business processes. For one, it is a client facing format. By that I mean it is intuitive to the client and represents their processes in a way that they can easily understand. Part II of this book uses swim lanes extensively.

Context Diagrams
One way to describe your process at a very high level is with the context diagram. It is a good starting point. A context diagram describes a rough process or a set of processes. It generally has only the following few components:
y y y y

A stick figure representing the external entity that is triggering the process A large circle representing the organization responding to the request A text block showing each organization or process acting to fulfill the request Arrows showing the rough flow between text blocks

The context diagramming process (shown in Figure 3.8) requires that the group identify one or more candidate processes. For example, a process might start with a client request or action and end with a fulfillment. The modeling activity starts by identifying those two points. You show the process start by using an arrow from the client to the organization. You show the process end by using an arrow from the organization to the client. That provides an initial bounding of the process, and the group can decide whether that particular process has enough issues to warrant more time diagramming. If the process merits more discussion, the diagramming process continues by identifying the first group to receive the request and the action sequence that the organization performs to fulfill the request. Simply put, the group uses Post it notes and arrows to show what goes on in the organization to fulfill the request. This should be done at a high level, and the constrained area of the circle helps maintain this high level perspective.

Figure 3.8: Context diagramming process Frequently the group will make refinements as they go. The most common refinement is a clearer identification of the existing client being focused upon or the transaction being performed. For example, client might become existing client if the process is different (or should be different) for an existing client versus a new client. The group can then annotate the process with success criteria, issues, and so on.

Business Process Work Flow Diagrams

When you need to identify the actual and ideal path that any product or service follows for the purpose of assessing process quality and to identify deviations and improvement opportunities, the flow chart is an excellent tool to use. It is a picture of steps in a process, and can be used to

examine the relationship and sequence of steps; to identify redundancy, unnecessary complexity, and inefficiency in a process; and to create common understanding of the process flow. Considered one of the simplest tools, the flow chart can be as basic or technically intricate as the process it is used to illustrate. Each type of process step is traditionally identified on the chart by a standardized geometric shape. A flow chart illustrates a process from start to finish and should include every step in between. By studying these charts, you can often uncover loopholes, which are potential sources of trouble. Flow charts can be applied to anything from the travels of an invoice and the flow of materials to the steps in making a sale or servicing a product. In process improvement, flow charts are often used to clarify how a process is being performed or to agree upon how it should be performed. When a process is improved, the changes should be noted on the flow chart in order to standardize the revised flow. Follow these steps to create a flow chart: 1. 2. 3. 4. Decide on the process to be diagrammed. Define the beginning and ending steps of the process, also known as boundaries. Describe the beginning step using the Boundaries symbol. Keep asking What happens next? and writing each of the subsequent steps in Operations symbols below the Boundaries symbol. 5. When a decision step is reached, write a yes/no question in a diamond and develop each path. 6. Make sure that each decision loop reenters the process or is pursued to a conclusion. 7. Describe the ending step using the Boundaries symbol. Sometimes a process may have more than one ending boundary.