Case in Point

I recently met a man who is a business process analyst. I spoke with him about a new job opportunity that he was considering. He said that he didn’t know what software application the company uses, but that it doesn’t matter. He has specialized in the distribution business and enjoys coming into new organizations, observing their current procedures, and making recommendations. He said to me: “You get an order, you pack it, and you ship it. How difficult can it be?” He had just named the essential processes in his business area. This was not meant to minimize the complexity of the distribution process. After working at many different companies, selling many different products, using different inventory and shipping software systems, he recognized that the core business processes are the same.

Table 4.2: Differences Between a Process and a Use Case
Process	Use Case
Business activity	Goal of the system needed by a particular actor
Named with a verb describing the work performed by the business (validate order)	Named with a verb describing the action taken by the actor (place order)
Defined without reference to who performs it	Tied to a specific role (the actor)
Defined so that it could be performed by any business worker and/or an external customer/ supplier/vendor	Designed to be executed by the actor (often specified as a conversation between the actor and the software)
Always defined as independent of specific procedures or technologies	Business use cases may be independent of tech-nology; system use cases describe how the soft-ware will support the activity

What Is the Difference between a Process and a Use Case?

Use cases have become very popular and are used by some project teams instead of processes or even in lieu of any other requirements components (see Chapter 6). Be sure to understand how your organization uses these requirements components. Because processes are defined independent of the who and how, they are more easily reused and allow for more design flexibility. Table 4.2 lists the differences between processes and use cases. Both should be defined independent of any current organizational structure or title.

Describing a Process

As each business process is identified and named, detailed questions should be answered about why it is done, what information it uses, and what business rules constrain or guide it. The successful analyst will delve deeply into each essential business process to make sure that its purpose and fundamental value to the organization are captured. Many of these questions may be difficult for subject matter experts to answer. The analyst must work with the business stakeholders to talk through the whys and whats of the process because only a deep, thorough understanding will give rise to improvements. By discussing each process in detail, the business subject matter expert thinks about the work in a new way. Often during analysis work, the subject matter expert comes up with a process improvement idea. This occurs because the process is being examined from a different perspective. Figure 4.1 is a template for describing a business process.

Naming processes is important yet is often done carelessly. Names should be chosen to accurately communicate the activity of the business (verb-noun), so that when the process is shown on diagrams, it is immediately recognizable. Process names should describe the what, not the how. Analysts can use the assumptions of perfect technology and the business glossary to help determine good business names.

Strong verbs to use in process names include:

• Accept

• Add

• Calculate

• Capture

• Communicate

• Delete

• Dispatch

• Generate

• Place

• Prepare

• Provide

• Receive

• Record

• Remit

• Request

• Send

• Submit

• Tabulate

• Update

• Validate

• Verify

Figure 4.1: Business Process Template

In addition to a strong, clear name, a description of the process must also be written. A name can only convey the basic information about what type of activity (the verb) is being performed on what type of data (the noun). A few sentences will elaborate on this name, providing all stakeholders with a clear, consistent understanding of the process. This description should explain why the process is important.

Analyzing a process includes understanding which, if any, external agents (organizations, people, and systems) interact with it. Most processes are performed in a business because an external agent has requested something. Understanding which externals are involved with each process provides additional information about why a process is performed.

During process analysis, it is important for the analyst to ask questions about sequence. What happens before this process (i.e., what triggers it)? What other processes are triggered by the completion of this one? And most importantly, why are processes performed in this order? One of the common mistakes made by new analysts is assuming that the current order of work is a requirement and must be maintained. This assumption locks the business into its current procedures and leaves little room for creative new solutions.

Each process must be examined for business rules. There will not always be a rule for every process, but most processes are guided by some type of a constraint (e.g., invoices are paid on the 15th and the last day of each month). As you are identifying business rules that are used during a process, think about whether each rule may also be used by another process. These shared rules should be defined consistently and their descriptions reused to save analysis time. Business rules will be discussed further in Chapter 6.

For each process, the analyst should think about the individual data elements needed to successfully perform it. These data elements may (1) come into the process from an outside source, (2) be created by the process, or (3) be retrieved from a storage facility (filing cabinet, database) inside the business. Businesses store a lot of data so that processes can use them whenever needed (e.g., customer addresses are stored in a database so that customers are not asked for their address every time they place an order). Process analysis includes verification that all of the data elements needed by a process are available to it. The importance of data requirements will also be discussed in Chapter 6.

While analyzing, naming, and documenting essential business processes are important work of the BA, understanding how a process is currently performed can sometimes be just as important. Often, when you are asking stakeholders questions about the core business activity and working to understand it independent of current technology limitations, they want to talk about the how. They feel that it is important for you to know, step by step, how they perform this business process. Listen carefully and make the notes that you need. Listen for gaps in the process or between processes. If you know that the technology currently supporting the process will be changing, understanding details about the current how may not be critical. Listen for problems and complaints to make sure that the new design will address the issues.

In addition, make notes about metrics. How long does the process take? How many times is it performed? Make sure you also understand who currently performs the process and who benefits from it. All of these things may change as your team brainstorms about alternative solutions. Understanding how the work is currently done prevents you from redesigning the same system. Finally, when talking with stakeholders about a process, listen to their suggestions for changes. They may have some great ideas about how the process could be made more efficient.

When the reason for a process is understood, as well as its constraints and data components, different creative approaches to accomplishing it can be imagined. In what ways could the business receive an order ? Via a text message? In an e-mail message? On a handwritten note? Suppose the products being sold are car parts. Could the car itself send an electronic message when one of its parts is wearing out and place an order for a new one? Figure 4.2 shows an example of an essential process: accept a customer order. This core business activity may be performed successfully in many different ways (different hows). When business requirements and processes are documented independent of current technology, they can be reused on future projects in the same business area. This can save the BA a significant amount of time.

Figure 4.2: Business Process: Accept Customer Order

This is where an analyst’s creativity can really shine. True innovation occurs when the innovator strips away the current procedures and looks at the base requirements. Then he or she can be creative in meeting those requirements. When you see a new product or service offered, think about how the inventor might have come up with the idea. Was it in response to a problem? Was it designed with the goal of increasing productivity or quality? Was it created to increase sales? Remember the primary business drivers (i.e., increase revenue, decrease costs). Any improvements made to an individual process roll up to help the entire organization.

In consumer product development, a brainstorming technique is used for package design. Think of an everyday common consumer product like soup. Now think of different types of packaging used for other items and imagine selling soup in that packaging. Soup in a box? Soup in a tube? Soup in a cylinder? Soup in a plastic jug? This technique illustrates the importance of finding the core business component and imagining it being presented in different ways. Once an essential process is understood, the analyst, business stakeholders, and solution team can imagine different procedures and systems that would support it.

Excellent BAs balance creativity with facts or metrics. Each process should be measured for its resource use, time to complete, efficiency, and number of times performed.

Process improvements are evaluated by their improved metrics. Can the improved system get the process done faster? How much faster? Can the improved process allow the organization to handle larger volumes of transactions? How many? Will the improved process result in higher quality products or services? By how much? Excellent business analysis professionals ask these questions because they understand that measuring process improvement quantifies the success of a project.

Six Sigma® is an approach to business process improvement that relies heavily on metrics. Sigma is a Greek letter assigned to represent the amount of variation or inconsistency exhibited by a measurable outcome. The name Six Sigma refers to the mathematical boundary within which errors are allowed. A Six Sigma capable process has a targeted quality performance goal of no more than 3.4 defects per million opportunities. The objective is to eliminate defects and variations in processes. When processes and their results are consistently measured, an organization can monitor improvements in efficiency and quality. It can also recognize decreases in productivity and respond more quickly. More and more organizations are using metrics to monitor performance. They are also building and buying complex business process monitoring systems and assigning process owners inside business units to monitor process effectiveness. To learn more about Six Sigma, read The Six Sigma Way: How GE, Motorola, and Other Top Companies Are Honing Their Performance (Pande et al., 2000).

When an essential business process is analyzed and described, this business requirement can be reused again and again. A business requirement is reusable when it is described independent of current procedures and technology. To help describe processes without embedding current technology, use the concept of perfect technology.