Executing a Business Model
A business model can be studied, analyzed, and simulated. Some business models can also be executed. When a business model is executed, it becomes software that supports running the business. Instead of being a description of the business, an executed business model becomes part of the business. It is integrated into the business’s day-to-day operations.
In the first six chapters of the book we introduced business modeling and the four business modeling disciplines. In the following three chapters we recommended best practices for creating business models. In the two chapters after that we described how to analyze and how to simulate business models. In this final chapter we explore how to translate models into software that runs the business.
Translating models into software is optional. Business models provide value without being translated to software. Business models allow a business to evaluate the impact of a change, analyze a proposed reorganization, or perform a competitive analysis. Business models are valuable in the many different ways that we have explored through this book.
But some organizations reap a further benefit from business models. They execute their business models. Executing a business model means translating it into application software and then running that software to benefit the business. By executing a business model, these organizations ensure that their business models are actually used. They avoid one common and tragic fate of business models: sitting on shelves, not used by anyone.
Business Modeling Life cycle
The management of business models—from their inception through maintenance and execution—is challenging. If a model is not maintained, it gradually becomes out of sync with the business reality that it models. Ultimately it becomes useless. When a corporate reorganization occurs, the business organization model must also change. Roles within business processes could change as well. When a new law is enacted and as a result the business forms new policies, the business rule model must change.
When a model is executed, maintenance becomes more important. Now software must be kept in sync with the business model, which must be kept sync with the business reality. When the business model changes, a software developer might need to add a new user interface form, or reconfigure an application. Sometimes a business model must be modified to reflect application changes. One small change to an application might change who should perform an activity.
The business modeling life cycle is the process by which business models are created, used, and maintained. Organizations often standardize on a business modeling life cycle to better manage the maintenance of their business models. Figure 12.1 shows a business modeling life cycle.
In the first activity of the life cycle—Model—a model is created. The model is created using the disciplines and practices we describe in this book. At the second activity—Analyze and Simulate—the model is simulated and analyzed. As a result of the simulation and analysis, the model might be changed. For example, simulated results for cycle time could differ from measured results for cycle time. The simulated results are used to refine the model; hence the sequence flow from Analyze and Simulate back to Model. Sometimes there are several iterations between these two activities.
The third activity of the life cycle is Deploy. When a model is deployed, it is converted into a format that allows it to execute as an application. This conversion may involve software development performed by people, or it may be a purely automated process, simply converting the model from a format that cannot be executed to one that can be. We discuss how to deploy business models later in this chapter.
The fourth activity is Execute and Monitor. Now the model is executed. If the model had driven application development, the newly created application is now run. If the model had been converted to execute in an engine, that engine is now run. In either case, the executing model is monitored. Data is collected about the model.
The last activity of the life cycle is Measure and Improve. The collected data is analyzed and compared with the expected values. The results are then fed back to the modeling effort so that the model can improve.
The life cycle repeats. Measurements lead to model refinements that are then analyzed, simulated, deployed, and executed. The model improves over time. With each cycle the organization learns. The measurements indicate whether something should be changed. Based on the measurements, the organization makes changes to the models or to the business, and then reevaluates the models through additional analysis and simulation. The business environment continuously changes—no matter what we do—and the business modeling life cycle allows an organization to continuously adapt the model to the changing reality.
The business modeling life cycle allows an organization to manage change and continuously improve. There are several benefits to this incremental approach. First, changes to the business are evolutionary instead of revolutionary. Instead of being confronted with a sweeping redesign, employees see smaller, more frequent changes. At each step the employees can adapt more easily. Small course corrections can be taken if needed. Overall, there is less resistance to the change.
Second, the incremental approach leads to better management of the risk. Instead of risking a large failure, the organization can manage many small successes. When one of the incremental changes fails, it is a small setback, not a disaster. The organization can correct course, derive value from what was learned, and continue to the next incremental change.
Third, the organizations can manage the rate of change and associated cost. Instead of a big up-front investment in a large reengineering effort that might not produce the expected results, the organization can make a series of smaller investments in smaller changes. The organization can determine the amount and the rate of change that best fits its economic situation.
From Models to Software
There are three alternative ways business models can be executed. These three alternatives are shown in Figure 12.2. The first alternative is manual execution. When a business model is executed manually, the model is used by people to design software that supports the model. The business model is studied by software developers, and the model helps the developers make decisions about what software to create and how to create it. Business models drive the early stages of software development: the planning and requirements gathering.
An alternative to manual execution is packaged execution. For this alternative the end state is not custom software. Instead the end state is a software package, perhaps a third-party commercial package that can be configured in thousands of different ways. The business model is used to select and configure the package.
A third alternative is direct execution. When a business model is executed directly, the model is interpreted by an appropriate engine and run as though it were software itself. A business process model is interpreted by a business process engine. A business rule model is interpreted by a business rules engine. In either case, the business model is not studied by software developers attempting to translate it to software. Instead it is directly executed by an engine to produce the desired behavior.
Next we explore each of these three execution alternatives, starting with manual execution, then packaged execution, and finally direct execution.
Manual Execution
When creating a software application, systems analysts or software engineers often start by writing a description of what they are trying to achieve. This description is called a requirements specification. The requirements specification details the intent of the application to be built—what it should do to meet the needs of its users. Requirements are important for the success of an application development effort. Without good requirements, application development projects often fail.
One popular approach to capturing application requirements is to write use cases. Use cases describe the behavior of an application—not the internal implementation details of how it works but rather what the application does and how it behaves for people who interact with it. Use cases describe the functionality the application provides to the people who use it.
The people who interact with an application in a use case are called actors. Use cases describe the actors, what the actors do to the application, and what the application does in response.
Each individual use case describes a single goal or task that an actor is trying to achieve by using the application. The use case describes the steps by which the goal (or task) is achieved: what the actor does, what the system does in response, then what the actor does, and so on. A use case reads like dialogue in a two-character play, with one character talking and then the other, except of course that one character in this play is software instead of human.
Use-Case Descriptions
Let’s look at an example. As you may recall from Chapter 5, when a Portia party is waiting for a table they are given a pager to alert them when the table is ready. Sometimes a party decides to leave before they are alerted. They give their pager back to the restaurant host, and he cancels the pager so it can later be provided to another waiting party. One of the use cases of the paging system is Cancel Pager, what the host does to notify the system that the pager is no longer in use, and that the party that had the pager is no longer waiting for a table.
Figure 12.3 shows the Cancel Pager use case. The use case includes a name, a description summarizing the use case, and the actor who interacts with the system. The use case includes a precondition that must be true before the use case can start: that the host is already logged in. Cancel Pager includes the trigger that causes the use case to happen: the pager being returned. Cancel Pager describes the basic flow through the use case when there are no errors or problems, the seven steps from beginning to end. Also described are three alternate paths. Each alternate path describes a single situation that might happen instead of the basic flow, and what results if the situation does happen.
Use Case Diagrams
In addition to use case descriptions like the one in Figure 12.3, use cases are often shown in a use case diagram like that of Figure 12.4. A use case diagram shows several use cases from the same application. The actors for the use cases are shown connected to the use cases in which they are involved. Figure 12.4 shows four use cases of the pager system as well as two actors: the host and the dining party. The host is an actor for all four use cases, and the dining party is an actor for one, the Send Alert use case.
In the Assign Pager use case the host records the name of the dining party and assigns a pager to them. In the Send Alert use case the host signals to the dining party that a table is available, and the diner’s pager buzzes. This use case includes the dining party as an actor since they see and hear the alert. In the Return Pager use case the diners return a pager to the host after it buzzes. In the Cancel Pager use case the diners return a pager when they decide not to wait for a table.
Use Cases and Business Modeling
Use cases are models, in many ways like the business models that are described in this book. But use case models are different from business models in one critical way: a use case model is a model used by software developers. It describes the requirements for software, not the details of the business that uses the software. The business models in this book describe the business, not the technology that supports the business.
The business and the software requirements are of course related, and business models can support the development of use cases for a new application. A business motivation model can capture the rationale for a new system implementation. A business process model can capture who is doing work and what activities they perform. The people who are doing the work often become actors in a use case model. Many of the activities in which the work is done are supported by use cases.
In Chapter 5 we considered the to-be business process for Portia after the implementation of a pager system. Now let’s turn to the development of the pager technology, work that is accomplished not by Portia but by Memphis Restaurant Technology, a vendor of pager systems with which Mykonos has contracted.
The Portia process is shown again in Figure 12.5. Several of the activities in Figure 12.5 are supported by the pager system. In the activity Ask Party to Wait, no table is available to the party and the host asks them to wait for a table. At that point the host assigns a pager and gives it to the party. The activity is supported by the use case Assign Pager. Later a table becomes available and the host alerts the party in the activity Alert Waiting Party. The activity is supported by the use case Send Alert. The alerted party responds to the alert in the activity Respond to Alert. That activity is also supported by the use case Send Alert because their behavior begins only after their pager buzzes. They then present their pager to the host, who collects it and assigns them a table in the activity Assign Table. That activity is supported by the use case Return Pager. Finally the waiting party may choose to give up on waiting for a table and leave the restaurant. They give their pager to the host, and he cancels it in the activity Cancel Waiting, supported by the use case Cancel Pager.
Note that a use case can support more than one activity. The use case Send Alert supports both the activity Alert Waiting Party and the activity Respond to Alert. In Alert Waiting Party the host starts the pager buzzing, and in Respond to Alert the dining party notices the pager buzzing. Both actions are part of the same use case, Send Alert.
Figure 12.5 shows the pager system use cases overlaid on the business process activities, showing which use cases support which activities. Figure 12.5 is not intended to be a new kind of diagram. Rather it is a normal business process model with a few use cases overlaid on top and arrows depicting the support associations between use cases and activities. Alternatively, these support associations across model elements in different disciplines can be shown as in Figure 12.6, in the same way that we have shown the tracelinks between (for example) business rules and gateways in Chapter 6.
Figures 12.5 and 12.6 show which use cases support which business process activities, but they do not show how the use cases are developed. How does Memphis Restaurant Technology decide to create a pager system with these four use cases? Why these four? Why not others?
There is a simple way to decide which use cases to create: walk through the business process. The systems analysts start with a business process model like Figure 12.5 and walk through each activity (and each gateway), asking whether that activity should be supported by an application. Some activities and gateways will not be supported; they will remain manual. For example, Monitor Tables is a manual activity. The host simply keeps an eye out for any tables from which a party is leaving. Some activities and gateways are supported by other applications. For example, the gateway Reservation? is supported by a reservations system, a different system than the pager system. And some activities need to be supported by the new system under design.
Use case models are a convenient place to trace a business model to models of a software application. Just as we trace activities from business process models to goals and strategies from business motivation models, we can trace use cases to the activities they support.
Packaged Execution
Instead of creating new software, many organizations choose to purchase an existing software package that more or less fits their business needs. There are many of these third-party applications available to support a range of common business functions: financial management, human resource management, sales management, and many others. Organizations that purchase a third-party software package can end up paying less and getting more: spending less money than if they develop and maintain the software themselves and getting a world-class application that has benefited from the experience of hundreds of other organizations.
But there is a problem with third-party software packages: they often do not fit the business (as you may recall from the Chapter 1 case study). The business processes supported by a third-party package are different from the business processes performed by the organization that is considering the purchase. For example, Mykonos is planning to purchase a third-party procurement package, and they must consider whether the package fits the Mykonos procurement business process.
The possibility for misfit is broader than just business processes. Third-party packages also make assumptions about organization, and their assumed organization can be different from the actual organization of the purchasing company. Third-party packages make assumptions about business rules and business policies, and their assumed rules and policies can be different from the actual rules and policies. In short, every third-party package comes with an assumed business model and that business model might be very different from what is desired.
The problem of third-party package fit can be addressed in one of three ways: by selection, by conformance, or by configuration. A company purchasing a third- party application package can evaluate the candidate packages based on business model fit. The company only selects a package whose business model closely fits their own. Alternatively, a company can purchase a package and then conform their business to the purchased application. They change their business processes, business rules, and organization to match the software they purchase.
The third alternative is configuration. Most third-party packages can be configured; the customer can change the behavior of the package. Typically configuration is performed by setting parameters values or by adding bits of custom software. Sometimes the package software can actually be changed. The work of configuring a third-party application is commonly called package implementation. Package implementation is performed by specialists—people who have training and experience in the implementation of that particular package.
All three alternatives benefit from business modeling. When a package is selected, the company’s business model is compared to the business models of the candidate packages. Which package supports business processes that most closely match the purchasing company’s processes? Which package supports organizations that most closely match? Business rules?
If the company chooses to conform to a purchased package, that conformance is a kind of business transformation that can be driven by business models. The company’s existing business processes become the as-is and the business processes supported by the package are the to-be. By modeling both as-is and to-be, the company can better understand what has to change.
Package implementation also benefits from business modeling. The hard and laborious work of deciding how to set configuration parameters is easier when the people implementing the package can refer to models of business processes, business organization, and business rules. Note that there is no magic in this approach. The package implementers use the existing business models as they use other reference materials.
Using business models to select, conform to, or implement a package is called packaged execution. Historically, package vendors have been skeptical of packaged execution, skeptical of the usefulness of business modeling in implementing their package. They have tried to convince their customers that their package has all the features needed and that modeling either the customer’s business or the business supported by the package is a waste of time.
But now the situation looks different. Many large package implementations have failed, sometimes after organizations spent hundreds of millions of dollars. It is now clear that there is more to package selection than feature lists. It is clear that conformance to a package is often hard and expensive. And it is clear that package implementation is a large and risky activity that benefits from the time savings and risk reduction that business modeling offers.
Direct Execution
Instead of developing a custom application or implementing a third-party application, a model can run in a special-purpose engine. Running a model in a special- purpose engine is called direct execution. A business process is executed directly as software in a business process engine. The engine interprets the business process activities, the roles that perform the activities, and the logic associated with gateways and flows. A business rules engine interprets the business rules, noting when a rule is violated and informing either other software or people of the violation.
Direct execution has several advantages over both manual execution and packaged execution. Direct execution can be realized much faster. The model becomes working software much quicker when it is directly executed than either when it is translated to custom code or when it is used to implement a package. Software development takes time: requirements are developed using the business model, software is designed, a graphical user interface is developed, the code is written and tested, and finally the code is installed. All this takes months, maybe years. Package implementation also takes time, sometimes as long as software development. By contrast, when a business process is deployed to a business process engine, little new software is written. A graphical user interface sometimes needs to be created to support the process, but the logic to control workflows is built into the engine.
Direct execution supports more agility. When a business process needs to change, the model is changed and redeployed. By contrast, custom-developed software is notoriously difficult to change, often requiring months of analysis, coding, and testing to implement a single business process change. An implemented application package can be fast to change if the desired change happens to be something easy to implement in the package. Other changes are difficult, and some changes are impossible to make.
Direct execution requires less ongoing maintenance. The custom-developed software that results from the manual execution of a model always requires significant maintenance. Bugs are discovered and must be fixed. New operating systems and databases must be supported. New mandates and business policies lead to new use cases. The same forces are also in play for directly executed applications, but each is easier and faster to implement.
But the technology for direct execution is not yet mature. Today there exist special-purpose engines to execute only two of the four business modeling disciplines. Business process models can be executed in a business process engine, and business rules can be more or less executed in a business rules engine, with some caveats as described later in this chapter. But today there are no special-purpose engines to execute business motivation models. One could imagine a business motivation engine that imported a motivation model and tracked progress against the goals and objectives, connecting the motivation model elements to personnel performance planning. Such an engine does not exist today. Similarly, there are no special-purpose engines to execute a business organization model. Even the business process engines—the most mature of the four—have some shortcomings.
Executing Business Rules
As you may recall from Chapter 6, business rules often are implemented in software applications. Consider again the rule about the acceptance of euros as currency.
Euros Allowed: It is permitted that a cash payment employ European Union currency only if the cash payment is applied to a bill and the amount of the bill is at most 100 U.S. dollars.
Euros Allowed can be implemented in the Mykonos point-of-sale system. When the server collects the cash provided by the customer and records the payment in the point-of-sale (POS) system, she selects the currency in the user interface, selecting euros instead of dollars. The POS system checks the amount of the bill, and if the amount is more than $100, the system rejects the payment with the warning dialog box shown in Figure 12.7. As you can see, the text of the error message is the rule that is violated.
How does it happen that the rule Euros Allowed is incorporated as part of the point-of-sale system? Earlier in this chapter we explained how there are three ways a business model can be executed as software: manual execution, packaged execution, or direct execution. For business rules, all three ways are practiced, but the most common of the three is manual construction. Today most business rules are implemented in software by someone reading the rule and writing application code that implements the rule. Package implementation is common, but most commercial software packages have limited support for business rules. Direct execution of business rules shows promise—and could become the dominant practice in the future—but today it is still a niche activity.
There are some significant shortcomings with the manual execution of business rules. Construction of software is always time consuming and expensive. A business rule must be understood by a software developer and manually translated into code. In our example, the rule Euros Allowed must be understood, and code must be developed to check whether the rule applies whether the currency of the payment is euros and the amount is greater than $100. Code must be created for the error dialog box shown in Figure 12.7. All this code must be tested. The whole process takes time and money.
Manual execution also makes the business rules hard to change. Business rules are meant to be changed as the business circumstances change, but changing code to reflect new rules is much more difficult than simply changing rules. In the Euro payment example, suppose the business rule changes to accept Euros only for smaller amounts, those less than $50.
Euros Allowed B: It is permitted that a cash payment employ European Union currency only if the cash payment is applied to a bill and the amount of the bill is at most 50 dollars.
This simple change to the business rule has a not-so-simple implementation. First, the code sections that implement the rule must be identified—both the checking and the display of the dialog box on violation. Then both code sections must be changed. The changed code must be tested.
Direct execution of business rules is a better approach. With direct execution, the business rules are managed in a business rules engine. From time to time the application asks the rules engine whether some condition is allowed. For example, the restaurant POS system asks the rules engine whether a bill of $154 is permitted to be paid in Euros. The rules engine replies that such a payment is not permitted and provides the text of the rule that is violated, so the application can present that text in the dialog box of Figure 12.7.
With direct execution, no software developer is involved. There is no translation to software code. Instead the business rules engine works with the business rules as rules. When new rules are added or existing rules changed, the changes have an immediate effect.
Today direct execution of business rules is rare. The rules engines available today—the commercial products and the open source applications—execute production rules rather than business rules. Whereas business rules are written in a structured English understandable to businesspeople, production rules are written in a technical rules language that is often difficult for businesspeople to understand without training. For example, the following production rule—written in the open source production rules application JBoss Rules—is (roughly) equivalent to the business rule Euros Allowed.
$p: Payment(type == “cash”, currency = “euro”, amount > “100”)
System.out.println(“It is permitted that a cash payment employ European Union currency only if the cash payment is applied to a bill and the amount of the bill is at most 100 U.S. dollars”);
This production rule states that if a cash payment is made in euros for an amount of more than $100, that payment is to be retracted from the working memory of the rules engine and an error is to be printed. Furthermore, the rule is a member of a group of rules called “payments” and among that group has a salience (priority) of 12. As you can see, this production rule is more similar to code in a programming language than to the business rule Euros Allowed.
Many people are confused about business rules and production rules, calling production rules “business rules” and calling production rules engines “business rules” engines. Even some of the vendors of production rules engines have adopted the language of business rules to improve their sales.
But the gap between rules engines and business rules is not so broad, and it is narrowing. There are three alternative ways to close the gap—one that works today and two more promising approaches that are under development. Today, an analyst with the right training can translate a collection of business rules into production rules. This translation work is much simpler and faster than translating business rules into application code.
An alternative way to close the gap is for someone to create a business rules engine, an application that directly executes true business rules. At the time of publication, we are aware of no business rules engine, no engine that interprets business rules rather than production rules. But there is great interest in such an engine within the business rules community, and several vendors of production rules engines are considering the support of business rules for future versions of their rules products.
We are also seeing the emergence of another method for direct execution, a method that does not involve rules engines at all. Tools are under development that generate application code from business rules. They translate business rules into Java or .Net code that implements those business rules. This generated code checks for rule violations, and when a violation is detected, it does the right thing.
Direct execution of business rules is still early technology, a bit immature and not yet ready for widespread use, but in the coming years we expect this to change. We expect the technology to become mature, and we expect direct execution of business rules to become a mainstream approach.
Executing Business Processes
Business processes can be executed in a business process engine. Let’s consider a Mykonos example: the Mykonos expense reimbursement process. To support its 143 restaurants around the country, Mykonos has a corporate headquarters. The headquarters is located in Chicago and employs 79 people to manage corporate finances, perform human resources, acquire new companies, and provide services to the individual restaurants. The headquarters employees often travel to other cities to scout for acquisitions and to work with existing restaurants.
When a Mykonos headquarters employee travels from Chicago to Miami (for example) she incurs expenses for air travel, hotels, and so on. She pays for these expenses on her own, and then when she returns to Chicago, she submits an expense report and gets reimbursed.
Figure 12.8 shows the business process for expense reimbursement. An employee submits her expenses, including a description of each expense. She then sends the physical receipts because they are required for tax purposes. To better control expenses and prevent fraud, Mykonos requires a supervisor to approve the submission before finance issues payment to the employee. Once the supervisor receives the submission he reviews all the submission items, looking at the descriptions. If everything is in order the supervisor approves the submission. If something is missing or incorrect the supervisor returns the submission to the employee, who must correct and resubmit it. Upon approval, the submission is forwarded to Finance. Finance must receive both the approved submission and the receipts in order to process payment.
The reimbursement process is both manual and riddled with problems. Sometimes the supervisor takes too long and the reimbursement is delayed. Sometimes the supervisor rejects the submission due to insufficient justification for the expense, but the paperwork sits in internal mailboxes and the employee does not find out until weeks have passed. The delays in reimbursement burden the employees who have already paid for travel expenses out of pocket.
Business Process Management Systems
Mykonos decides to execute the expense reimbursement process in an engine. They use a business process management system. A business process management system—commonly abbreviated as BPMS—is software that combines business process modeling with process execution. A BPMS allows an organization to both model and execute its processes, to ensure that those processes are followed. The BPMS assigns activities to people, tracks whether those activities are completed, and once they are completed, routes the appropriate forms and documents to the next person who is performing the next activity. A BPMS supports both activities that require user interaction and activities that are automated.
Mykonos has acquired a BPMS to execute all its internal corporate processes, not just expense reimbursement but also procurement processes, accounting processes, and human resources processes. For the expense reimbursement process, an expense report is routed from an employee to the appropriate supervisor so that it can be approved. The BPMS ensures that the right activities are performed. Reimbursements cannot be paid until the employee submits both expenses and receipts and until the supervisor approves the expenses. The supervisor must approve or reject a submission within three business days. If he takes longer, the BPMS produces alerts.
Figure 12.9 shows the expense submission entry page, the page presented by the BPMS when the employee is performing the Submit Expenses activity. The employee can enter an expense purpose and a dollar amount. Once entered, the new expense is added to a table showing the whole trip. For each expense, the BPMS determines whether a receipt is needed. When the employee completes the entries, she presses the button labeled “Submit Expenses.” Then the submission is routed to her supervisor for the next activity, Review Submission.
Figure 12.10 shows the page Finance uses when they perform the activity Check Submission. Finance can see a submission and the related employee information. They can also see who approved the expenses. There is an (unlabeled) gateway in Figure 12.8 immediately before Check Submission. The gateway shows that finance must receive the receipts in order to check the submission. If receipts were received the finance department user can click on the checkbox and then press the “Issue Payment” button. This action sends the instructions to the third-party payroll system to issue payment to the employee. If the submission is not compliant with expense policy, Finance can reject the submission, placing it back in the employee’s to-do list.
Using a BPMS to manage a process such as the one shown in Figure 12.8 involves several steps. These steps include deploying the business process, creating a user interface to represent the various screens that are needed, and data mapping and integration with other applications and systems.
Deploying a Business Process
A BPMS executes business processes. But the BPMS does not directly execute the visual diagrams created by the modeler, the diagrams like Figure 12.8. Instead a model must be first transformed into an executable format that can be interpreted by the BPMS engine. This transformation of a model to an executable format is called deployment.
When a modeler is ready to deploy a model, the BPMS checks the model for problems that would prevent the model from being executed. For example, if the BPMS finds a business process with no end event, it warns the modeler. Activities are checked to ensure they have both incoming and outgoing sequence flow.
If the model passes the checks, the BPMS translates it into a form that can be interpreted by the BPMS engine. The engine is able to route work from one user to another—for example, to route the expense submission from an employee to his supervisor, and then to finance. The engine is able to present Web pages to different users at appropriate points in the process—pages like those shown in Figures 12.9 and 12.10.
As part of deployment, the modeler indicates which activities are to be deployed. Not every activity is deployed. Some activities are purely manual and not supported by the BPMS. For example, Send Receipts—in which the employee sends his receipts in the mail—is a manual process and is never deployed. By contrast, Submit Expenses—in which the employee fills in the travel expense form shown in Figure 12.9—is deployed.
One of the advantages of direct execution is agility in supporting change. The business changes, the business models change, and the deployed process needs to change. When change is required, the process is redeployed. The model is rechecked and translated again to the appropriate format, and then the newly changed process can be executed.
Creating a User Interface
Each deployed activity must be supported by a user interface page. For example, Submit Expenses is supported by the page shown in Figure 12.9. Check Submission is supported by Figure 12.10. Other pages are also needed: one for a supervisor to review expenses and one for Finance to see which submissions are waiting for checks. Someone must create these pages, preferably a user interface designer working with the modeler. Once created, each page must be connected to the activity or activities it supports. A good BPMS provides functionality for creating these pages.
The BPMS also provides some pages out of the box—pages that are useful for any executed process. Figure 12.11 shows one of these pages. In Figure 12.11, the user Joseph Ryan can select from a number of activities that are waiting for his action. He needs to revise his own expense submissions, one submission for a trip to Denver and another expense submission for October expenses not part of any trip. In addition Joseph Ryan supervises others. There are three expense submissions that he needs to review for three different people working for him. The BPMS provides the user interface shown in Figure 12.11 so he can see all the jobs that are waiting for him and he can select one of the jobs to work on next.
Note that the page shown in Figure 12.11 is not associated with any single activity from the executed business process. Instead it is a to-do list that spans all the activities that Joe needs to perform now. If other business processes were implemented in the same BPMS, the list could include jobs from those other processes also waiting for Joe’s action.
Data Mapping and Integration
The employee has entered an amount of $12.58 in the amount field of the page shown in Figure 12.9. That value of $12.58 is of course stored in a database, so it can be examined later when the expense submission is reviewed. But which database stores that field? The BPMS has its own database to keep track of information that only the executed process cares about. The BPMS also communicates with other databases at Mykonos for access to information that is already stored elsewhere.
A typical executed process uses a variety of data fields. The expense amount is one data field. The employee name is another data field. Each data field is a bit of information displayed, used, or changed in the executing business process.
Some data fields are private to the business process, used only inside the process and nowhere else. Other data fields include information pulled from external corporate databases. Some data fields even cause those external corporate databases to be changed.
When implementing a business process in a BPMS, the modeler—or a database guru working with the modeler—must identify which data fields connect to external databases and which data fields are private to the process, without any linkage to anything external. This activity of linking business process data fields to external databases is called data mapping. Note that data mapping is an integration exercise; to execute the process the BPMS must be integrated with other existing applications that own those databases.
Table 12.1 shows the data mapping for some of the fields in the expense reimbursement process. Some of the fields in Table 12.1 map to existing systems—either the Mykonos HR system or their general ledger. The BPMS pulls some fields from the HR system: the employee’s name, ID, and supervisor. The BPMS pulls the cost center from the general ledger to ensure that the expenses will be put in the appropriate categories. The BPMS also pulls the payment status from the general ledger.
Table 12.1
Mapping Data Fields to External Systems
| Field | System |
| Employee Name | HR system |
| Employee ID | HR system |
| Submission ID | (private) |
| Submission Amount | General ledger |
| Submission Status | (private) |
| Supervisor Name | HR system |
| Cost Center | HR system |
| Payment status | General ledger |
| Receipts | (private) |
Some of the fields in Table 12.1 are private, of concern only to the executing process in the BPMS, not to external databases. For example, the executing process must track the status of a submission, whether it has been approved or rejected. The executing process must also track whether receipts have been received by Finance.
Data mapping can be bidirectional. When a data field is changed, the appropriate external system or systems must be updated to reflect the change. For example, when the submission amount is changed, the general ledger must be updated.
Some data fields cannot be changed by users. For example, no one can change an employee’s name or ID, at least not in the expense reimbursement process. Other data fields can be changed. The employee can change the data field for the purpose of an expense by selecting from the pull-down menu in Figure 12.9. She can also change the amount of the expense by typing a new amount. Finance can change the data field indicating whether receipts have been received by checking the checkbox in Figure 12.10.
Data fields are associated with a job, flowing with the job from process activity to process activity. For example, the submission ID is associated with the job. As the submission is routed from Submit Expenses to Review Submission to Revise Submission, the submission retains the same ID.
The value of a data field can affect the flow of a job through the process. Receipts are not needed for expense items of less than $25. If a submission has no expense items that need a receipt, the job need not wait for receipts to be received. It can be approved for payment without any receipts.
Some data fields cannot be viewed by some users. BPMSs usually support the restriction of access to a data field, either for security reasons or for privacy reasons. Furthermore, not every field is shown on every page, even when there are no security or privacy issues. For example, the cost center data field is shown on the Check Submission page of Figure 12.10 but not on the Submit Expenses page of Figure 12.9. Finance needs this information even if the employee does not. Some data fields are also editable by some users and not others. The user can enter and change amounts for expenses, but her supervisor can only approve or reject. He cannot change the amounts.
Business Process Management
As we have discussed, business processes can be modeled using modeling tools. They can be analyzed. They can be simulated using a simulation engine. And they can be executed in a BPMS. The modeling, analysis, simulation, and execution of business process models is called business process management, often abbreviated as BPM. BPM is a big-tent term that encompasses a lot of practices involving the modeling of business processes. BPM is not just about executing a business process in a BPMS; it is about the continuous improvement of the process. BPM includes the roles and responsibilities in an organization. It includes the artifacts people use in performing their work. It includes the technology used. BPM is about the ongoing management, control, monitoring, and improvement of the business processes, and ultimately of the business itself.
Business Process Monitoring
How can we tell if the process we implemented is performing the way we expect? Does it match our simulation? Have we in fact lowered costs? Are we now conforming to the regulation? Most BPMS support the monitoring of an executed process. Since the BPMS is managing the progress of every job, it can measure how the process is performing. The BPMS can measure delays, it can measure the number of jobs in a backlog, and it can measure the efficiency of each activity. The real-time measurement of an executing business process is called business process monitoring.
Why is business process monitoring important? Monitoring is important because all models are wrong. The behavior of the executing business process will be different from what we expect and different from what we simulate. For example, a process that we expected to never develop a bottleneck will in fact bottleneck and do so at an activity that surprises us. And even if a process behaves according to our expectations this week, next week will bring new business conditions and new process behavior. So we monitor our processes to learn how they are actually behaving, to adjust them, and to improve them.
Many aspects of a process can be monitored. In practice, it is best to monitor the aspects that are important to the business. For example, for some businesses, customer order fulfillment time is important. For those businesses, we monitor that fulfillment time, how long it takes from when a customer order is received until that order is fulfilled. We monitor how that customer fulfillment time changes, how it rises and falls.
When we monitor a process we track its behavior and maintain relevant statistics. We monitor the sequence flows between the activities, we monitor the time it takes to perform each activity, and we monitor the queues—how many jobs are waiting and where they wait. We also monitor how many times an activity is performed, to track which sequence flows are executed and which are not.
Monitoring is performed in real time. End-of-week reports are not as useful as understanding where a bottleneck is building right now. If you see a bottleneck before it becomes too large, you can intervene—perhaps adding resources—before the problem is visible to customers or to other stakeholders. For example, part of monitoring the Mykonos expense reimbursement process is tracking the Review Submission activity. If too many submissions are waiting at this activity, an investigation is necessary. The delay in reviewing expense submissions could be because a supervisor is on vacation and neglected to assign someone else to approve his employees’ submissions. It might have happened because a supervisor has too many employees and cannot review all the submissions in a reasonable time. Or it could mean that the supervisor is simply delinquent in his duties.
Business process monitoring is often performed with a dashboard. Figure 12.12 shows two dials from a dashboard for monitoring the expense reimbursement process. A dashboard provides an easy-to-understand visual display of the important measurements within a process.
When we monitor a process we collect data on individual jobs flowing through a process. We also collect aggregate data, averages for all the jobs that flow through. For example, when we monitor the expense reimbursement process we monitor how long on average it takes to process expense submissions, from the time the expense submission is created to the time the funds are transferred. In addition to the averages, we also monitor and track the individual submissions. How long did submission 3910239 take?
More and more companies today are monitoring their processes, for several reasons. Business process monitoring allows a company to see how it is performing right now. When Mykonos implements business process monitoring, it can understand how its procurement process is performing and where there are bottlenecks in acquiring food and beverages.
Business process monitoring allows companies to see impending problems and address them now, before they get worse. For example, Zona is crowded every weekend, and delays are growing. Is it time to implement reservations-only seating on the weekends?
Business process monitoring is useful in investigating the impact of a change. When a process is tweaked, the effects can be monitored in real time to determine whether the change had a positive or negative effect. Did the implementation of reservations-only seating cut the customer wait-time as expected?
Simplifying the Business Process for Monitoring
Let’s consider an example of a business process monitoring of the same Mykonos expense submission process. At any time, Finance would like to know the number of unpaid expense submissions, the total dollar amount of those expense submissions, and how long it takes to reimburse employees. Finance would also like to understand the reasons for any delays in the process. Are employees paid late because of supervisor approval delays or because of delays in the third-party payroll processing?
Figure 12.13 shows the expense reimbursement process. Note that this is the same business process as shown earlier in Figure 12.8, but Figure 12.13 is much simpler. Many of the activities in Figure 12.8 are not present in Figure 12.13. Figure 12.13 omits the activity Review Submission because Mykonos does not care about monitoring that activity separately. The new gateway Approve Payment? incorperates both Approve Submission? and Complaint with Policies. Figure 12.13 also omits the activities related to the submission of receipts and the checking of those receipts, since those are manual activities.
Business processes are complex, showing us every activity that is performed to make the business process work. We only monitor a subset of those activities, so for monitoring, the business process model is always simpler. Typically we only include the most important sequence flows through the process, and we include only the activities that are needed to determine whether the business process is performing well. For monitoring, less is more.
Events
Business process monitoring monitors events. An event is simply something that happens, something that is noticeable by a system and noticed more or less when it happens. Our BPMS implementation can notice when expenses are submitted, so one event in expense reimbursement is Expense Submission. Other events include Expense Approval, Expense Rejection, Expense Revision, and Expense Payment. Together these five events allow us to monitor everything important in the expense reimbursement process.
Figure 12.14 shows how the five events relate to the simplified business process model used for monitoring. Each event occurs on one of the sequence flows. When we see an Expense Rejection event for some job, we know that the job has traveled on the sequence flow from Approve Payment? to Revise Submission and is now waiting for the employee to make revisions. Some time later, we will see an Expense Revision event for that job, and then we know the job is once again at Approve Payment? waiting again for a supervisor to decide whether to approve or reject it.
Events connect the execution of an activity to the monitoring of that execution. The BPMS knows when Submit Expenses is executed. At the moment the employee presses the “Submit Expenses” button (shown in Figure 12.9), the BPMS creates an Expense Submission event for the job that has just been submitted. Similarly, at the moment the supervisor presses the button approving the expense submission, the BPMS creates an Expense Approval event for that job. To monitor the process, only the events need be monitored.
Dashboards
As a process is monitored, its state needs to be presented in a meaningful way to a variety of stakeholders. The presentation is typically performed using a dashboard. A dashboard is a one-page graphical display that shows the status of changing data. Most dashboards are web-based, so the users need not install any special software. Dashboards typically use graphical elements such as meters, gauges, and graphs to provide easy-to-understand status for measurements of interest. As the underlying situation changes, the graphical elements update, so the users of the dashboard always see the current situation.
Different stakeholders have different dashboard needs. The Mykonos COO would like to gauge whether managers are approving expenses and if there are any delays. He would like to track patterns and to address potential problems. The CFO would like to see the total outstanding amounts for reimbursements and how that changes from day to day. He would like to track expense amounts and predict the impact on the balance sheet and income statements.
Figure 12.15 shows the dashboard that the Mykonos COO uses to track performance of the expense reimbursement process. This dashboard shows the same process as Figure 12.13. The process is annotated with counts of the jobs that have passed through each sequence flow. By examining the process, the COO can determine that expense submissions are not bottlenecked at approval, but rather at Revise Submission and at Process Payment. The dashboard also shows the average processing time for an expense reimbursement and the number of outstanding submissions.
Each organization decides what measurements it wants to track and display, and at what level alerts should be raised. At Mykonos a backlog of 50 submissions waiting for approval is significant enough that the dial is red. For a company of 1,000 employees, a backlog of 50 would be trivial and the dial would be green.
Some dashboards support drill-downs so that the user can see the details of a particular job. For example, the COO might want to drill down to check on individual expense submission and see which activities have been performed and which are pending. He might want to check durations, seeing how long each activity took for that expense submission. He might want to see alerts, understanding where too many expense submissions have backlogged. This detailed information allows him to identify potential problems and address them.
To create good dashboards, you must understand the audience. What level of granularity is appropriate? Do they want to see bar charts or tables or dials? Do they want to see the current situation as it compares to normal conditions? Do they want to receive alerts when data is outside of the normal? Do they want to drill down into the underlying jobs?
Business Activity Monitoring
For monitoring the expense reimbursement process we harvested events from the BPMS. The BPMS provides the events Expense Submission, Expense Approval, Expense Rejection, and Expense Payment. But the fifth type of event—Expense Payment—cannot come from the BPMS. The payments are actually made by a third-party payment service and the BPMS is not aware when those payments are made. We want to monitor the whole process—end to end—so we must find a way to generate events from the payment service.
This situation is common. Although a BPMS attempts to manage a process from end to end, some parts of the process are either supported by or entirely performed by third-party applications that the BPMS does not control. Most BPMS include some software for integrating to freestanding applications, for generating events so that we can notice when a job is performed outside the control of a BPMS. This software is called a business activity monitoring system, often abbreviated as BAM.
BAM notices when an existing system does something, creates an event when that something occurs, and ties events from multiple systems to show a single picture of the business process. Typically this involves some light system integration work. For example, in the expense reimbursement process, Mykonos invokes an application provided by the third-party payment service to direct the service to issue payment. The application reads in a file extracted from the accounting system that includes the ID of the expense and the amount to be paid. The application writes this information to a log file once the third party is directed to issue the payment. To implement business process monitoring on expense reimbursement, we monitor the log file and create the event Expense Payment to match the expense. Now our business process monitoring can notice when a payment is made.
Each legacy application is different. Some applications provide an application program interface, making it easy to notice events. Other applications are harder. Sometimes events can only be noticed by monitoring log files.
BAM complements BPMS, creating events for applications and services not orchestrated by the BPMS. But BAM can also be implemented as a poor man’s alternative to a BPMS, an alternative that offers some but not all the BPMS functionality. Most business processes today are supported by a collection of legacy applications. A BAM system can monitor an existing process in the way that it is currently executed, using those legacy applications. No changes need to be made except minor changes to notice events.
A BPMS implementation is a much more radical step than a BAM implementation by itself. A BPMS implementation changes the way people work. They must now use the BPMS implementation of their process to perform their work, using (for example) the page shown previously in Figures 12.9 to submit an expense report rather than the Excel spreadsheet they used previously. A BAM implementation is a less intrusive approach. After a BAM implementation, the process is performed exactly the same way, with the same legacy systems. The only difference is that the process can now be monitored.
Sometimes BAM is performed as a first step toward a BPMS implementation. The process is modeled, BAM is implemented, and now the process is visible for the first time. The areas for improvement are clear; insight is gained. A BPMS implementation uses this newfound insight.
Implications for Modeling and Execution
A business process model can provide a great deal of business value. Even more value can be achieved when the same process is executed within a BPMS or at least monitored by BAM. In either case, the business can see exactly what is happening. If the process is executed, the business can easily change the process, responding to changing conditions.
Today, most business processes are neither executed in a BPMS nor monitored with BAM. These technologies are still young, and their penetration is still small, in part due to simple awareness. Most business managers are not aware of the value they could achieve with model execution. The lack of awareness is due to the technical maturity of the technology. Today there is little interoperability among the BPMS tools. Processes often must communicate, but it is difficult to make a process implemented in one BPMS tool communicate with another process implemented in another tool. As a result, organizations are not able to achieve the promised value. As standards are adopted, we expect more organizations to directly execute their process models.
Direct process execution requires skills beyond modeling. Some software development, database, and integration skills are also required. Typically a team must be assembled to collect all the skills. Training is often also needed.
Process Improvement
In Chapter 10, we discussed improvement analysis and business process improvement. Business process monitoring is useful for analyzing the performance of processes and identifying areas for improvement. For example, Mykonos might have predicted that the expense reimbursement process would average two days’ cycle time—two days from the expense submission to payment. In practice, the cycle time averages more than 16 days. There appears to be significant room for improvement.
By analyzing the measurements we collect, we can understand why the process takes longer than we predicted. We use this understanding to improve both the process and our model of the process, as shown earlier in the business modeling life cycle of Figure 12.1. We cycle through, making changes to our original models. When our business environment is not changing quickly, each cycle leads to more modest changes and our process performance improves. Of course, sometimes the business environment changes quickly, and our cycles are instead focused on adapting to the changing circumstances.
The Future of Business Modeling
How can we expect the practice of business modeling to change over the next 10 years? Predicting the future is always a risky endeavor. Many unexpected things can happen. But the trends are certainly clear. Business modeling has become increasingly used over the last 10 years, and increasingly accepted. We expect that trend to continue. We expect business modeling to go mainstream over the next 10. Ten years from now almost all companies and almost all government agencies will use business models for the purposes we have described in this book.
In the coming years, we expect tooling to improve. In particular we expect that tools will become multidisciplinary, supporting all four business modeling disciplines. Today most modeling tools support only a single modeling discipline. The tools that support business process modeling have weak or no support for business motivation modeling. The tools that support business rule modeling only handle business rules. But as we have shown in this book, business modeling is not four separate practices. Rather it is a coherent whole, one practice with four disciplines. Ten years from now, we expect all the popular tools will support all four disciplines.
With the tooling support for multiple disciplines, we also expect the profession of modeling to change as well. Today the people who create business process models do not create models from the other three disciplines. The people who practice business rule modeling only create business rules. Today the tribes are separate. But business modeling is fundamentally a single profession, with many common best practices that span all four disciplines. Ten years from now, we expect business modelers will know and use all four disciplines.
We expect model simulation to go mainstream as well. Model simulation is a niche activity today. In our experience, fewer than 5 percent of all business process models are simulated today, and certainly fewer than 1 percent of all business motivation models are simulated. But simulation is becoming more popular, and we expect that trend to continue. Ten years from now, we expect most business process models and most business motivation models will be simulated. Companies and government agencies will routinely create business simulations to analyze new situations and to persuade their stakeholders and clients to undertake the right course of action.
Direct execution is poised to go mainstream as well. Direct execution promises the best approach for business model execution because the models can be easily changed to support changes to the business. As the tooling matures and direct execution becomes more widely understood, it will become the most common method of executing a business model. Ten years from now we expect direct execution to be the usual manner of executing a business model, with manual execution and packaged execution only practiced occasionally, in exceptional situations.
All this growth and mainstreaming makes today an exciting time for business modelers. There is much new opportunity for people who understand business modeling, and there are many new uses of business modeling for modelers to explore. But of course there are risks. As we have explained throughout this book, business modeling should never be practiced for its own sake. Business models should only be built and used when their use is justified by the economics. Only by keeping an eye on the practical value of your business model can you ensure that you build a model that is more valuable than the effort it takes to create it.
Business models can be executed. A business model can be executed manually, used as requirements for software development. A business model can be executed directly, run as software in an engine. Or a business model can be used to configure a packaged application. Direct execution is in many ways the most promising way to execute a business model, but it has limitations. Today, only business process models and business rule models can be executed directly.
A business process model can be directly executed in a BPMS. A BPMS supports the routing of business process jobs from activity to activity, from the person performing one activity to the person performing the next and from one user interface page to the next. But a BPMS implementation can be a radical step for an organization. A BAM implementation is a more conservative approach, monitoring a process as it is currently, supported by several legacy applications.