Why Use Business Process Software?

We have already suggested that a wide variety of different groups are engaged in different aspects of business process change. Those involved in process automation, for example, already use a variety of software tools to aid them in their work. They use modeling tools to picture processes and document requirements. They use Business Process Model and Notation (BPMN) tools to generate code. Similarly, those involved in workflow automation development use workflow tools to model applications and may then rely on those same tools to implement the results and manage the actual processes during day-to-day execution.

Business analysts and professional business process practitioners usually rely on software tools specially developed to support business process modeling and redesign. We will refer to these tools as professional business process modeling tools.

Business managers engaged in business process analysis and redesign, on the other hand, are less likely to use software tools. Surveys suggest that a large number of managers prefer written descriptions. Using this approach a process may be described as a numbered list of activities. Many use simple graphical or illustration tools, such as the introductory version of Microsoft’s Visio or PowerPoint, to quickly create flow diagrams. There’s nothing wrong with either written descriptions or simple graphics when one is doing informal analysis. When one wants to do something that can be saved, accessed by others, and reused, however, a software tool is needed that can store the models and the associated data in a database. A database specifically designed to store information about business processes is usually termed a business process repository. Most professional process modeling tools are designed to work with a process repository.

Many business process teams assign a team member to capture group discussions in a business modeling tool. During analysis and redesign a facilitator usually works with a business process project team to describe the existing or As-Is process and then to create a To-Be diagram. These sessions usually take place on two or three mornings during each week of the project. The facilitator usually stands in front of the group and makes notes on a whiteboard. Often, teams will use large Post-it notes to quickly create and then change large diagrams on the whiteboard. Thus each day the newly modeled process needs to be documented and changes need to be incorporated in earlier models. A software tool makes it easy to record the results of a morning session, to generate images that can be sent to participants’ computers, and to print out neat versions of the process diagrams for the participants. Some facilitators work with an associate who sits at the back of the room and records the session using a business process modeling tool. Others simply use the tool themselves to record the results in the afternoon following the morning session. Since modeling tools can save versions it’s easy to record different proposals so the group can document alternative versions of a solution.

Integrating paper documentation that shows processes and subprocesses, goals and measures, and the cost and capacity assumptions made about activities can be quite complex, but a tool makes it easy to keep all the information in a single file, providing a huge increase in the efficiency and productivity of the documentation process.

Some process modeling tools make it possible to simulate processes, so teams can study alternatives or check to see how the process would perform under different flows or constraints. Some managers use tools to track the ongoing results of measurements. In these cases the tool becomes a process management tool.

Finally, if a company is serious about developing a process architecture and expects to keep track of ongoing changes in processes and subprocesses they need a tool to manage and maintain all of their process descriptions. In this case the company should agree on modeling standards so that the outputs of business process redesign teams can be smoothly integrated into the overall model maintained by a process architecture committee.

Variety of Business Process Tools

There are dozens of different software tools available for business process change projects. Figure 15.1 shows how BPTrends defines the business process software market. The overlapping circles suggest that many products combine features from different technologies. In many cases the software vendors began by offering one type of tool—say, a business rule tool—and then as the market evolved repositioned themselves and offered something else—by becoming a business process management suite (BPMS) vendor, for example.

Table 15.1 provides definitions for some of the different types of tools shown in Figure 15.1 and suggests who might benefit most by using them. We have provided generic names, although in fact the various tools go by a wide variety of different names.

Some of the tools described in Table 15.1 are narrowly focused. Others fulfill more than one function. Thus, for example, there are business process modeling tools that are simply designed for one purpose—designing supply chain processes using Supply Chain Operations Reference (SCOR) notation, for example. There are also tools that allow business analysts to develop process diagrams that can later be converted to other notations for software development. There are workflow tools that combine business process modeling and the actual execution of a workflow application.

There are well over 100 business process software tools on the market at the moment. In part, this reflects the variety of ways that companies are approaching business process change. It also reflects the immaturity of the market. In the early years of the millennium we predicted that the business process management (BPM) tool market would mature and consolidate, leaving only a few, powerful BPMS tools. In fact, although there has been considerable consolidation, new vendors keep entering the market. This reflects a dual need for powerful, complex BPMS tools and at the same time a need for simple tools for less sophisticated process analysts and managers.

In the remainder of this chapter we’ll focus on only two types of process modeling tools, professional process modeling tools, and BPMS tools that can both model and then execute processes.

Professional BP Modeling Tools

Figure 15.2 provides an overview of the key features we expect from a professional business process modeling tool. It provides interfaces in which users can create organization and process diagrams. Unlike the simpler tools that only create diagrams professional tools store the model elements in a database, usually called a repository, so that any information gained can be reused. Similarly, whenever a user creates a modeling element on a diagram the user can click on the modeling element and enter information about the element. Thus if we create an organization diagram and name six departments we can later create a process diagram and have those six department names automatically inserted as the names of the swimlanes. Similarly, if we create a process called sell widgets and then define a number of activities that occur within the sell widgets process we can click on the sell widgets process in any diagram it occurs in and get to the diagram that shows the activities within sell widgets.

The heart of every professional business process modeling tool is a database, or the business process repository, in which all elements of a business process and all the relationships between those elements are maintained. Graphic tools—like Microsoft’s Visio, which is very popular among business modelers—only support diagrams that are equivalent to pages of paper that have a process diagram on them. Each page or diagram is a thing in itself. Creating one diagram doesn’t help you create the next. A professional business process modeling tool, on the other hand, stores each element in its database (or repository). Thus, as you create one diagram, you are storing information about processes and relationships that you can use on subsequent diagrams. As you proceed you rely less and less on drawing new elements and more and more on telling the database what previously entered elements you want to place on your diagram.

Most business process tools support some kind of code generation, if for no other reason than to allow users to pass information about a process to other process tools. Increasingly, business process tools will support an XML business process language. Most also support BPMN or some software language so that software developers can begin where business managers leave off. Code generation isn’t a feature that business process redesign teams need, but it can certainly make it easier when a business process team wants to submit a redesigned process to a software development team.

There are a number of other features that we don’t show in Figure 15.2. For example, if the tool is going to be used for Six Sigma projects it’s nice to have statistical utilities or a clean interface to a popular statistical package. If the tool is going to be used with a methodology like the Supply Chain Council’s SCOR methodology the tool should probably offer templates for SCOR models.

The key thing about using a professional modeling tool isn’t that it helps you do the initial process analysis, but that it serves as a database to store all the information you gather about the process as the analysis effort proceeds. Then, as the team goes from one process to another or drills down into a single process, the tool keeps track of each activity name. If you reuse a name the tool challenges you to ensure that this latest activity is the same as the earlier activity of the same name. If it is you automatically inherit all the information you have already defined for that activity. If it’s new the tool requires you give it a unique name, and so forth.

In a similar way, the tool is prepared to generate matrices as you accumulate information. Thus you may later want to know all the processes that a given department or manager is responsible for managing. A good process modeling tool can quickly generate such a list from its repository.

If you were working by hand you would have to create one diagram to describe the existing process and others to model each of the possible To-Be solutions your team might suggest. Using a tool one creates the As-Is diagram and then generates To-Be diagrams by saving a copy of the As-Is diagram and then modifying it. One can easily end up with a whole collection of Could-Be diagrams before one selects the final To-Be solution.

Similarly, once you have an As-Is diagram, you can choose specific activities to define in more detail, in effect creating new diagrams that describe the inner workings of activities on the original As-Is diagram. You can also enter information into tables associated with any given activity. Thus the team can list the job roles associated with each activity, list the time it normally takes to complete each activity, and list the costs of resources used in each activity. It can also list or point to business rules or decision tables associated with each activity. All this information becomes part of the database and is associated with the process whenever you do any subsequent process work.

Some professional modeling tools support simulation. Once you have provided information about how each activity works you can develop a set of cases (instances of the process with associated data) and run the cases to see how long a given set of cases would take. One often finds new problems during a simulation that would have been hard to anticipate when simply looking at a diagram. For example, it may be that you only have two employees assigned to a given activity, but that the activity takes quite a long time. The result, when large numbers of instances are being executed simultaneously, is that there is a bottleneck and that the process slows down because the two employees cannot keep up with the demand. Running simulations can quickly identify problems of this nature.

A modeling tool also makes it easy to keep track of when a process accesses a database. This isn’t something that a business process team worries too much about when initially redesigning a process, but it can be very important later, especially if the process model initially developed by the process team is later passed to a software development team.

Modeling and Management Screens

Whether you use a professional process modeling tool or a business process management suite you will use a combination of graphics and tables to record information about the business processes you want to analyze and then redesign. Both types of tools require that you learn how to use them. They are more complex than simple modeling tools because they require that you create a repository to keep track of all the processes, activities, flows and roles that are involved in each process. The reward is that the tools will provide considerable assistance as you move on to more complex modeling.

The screen images that follow suggest some of the types of interfaces you will need to learn to deal with. We have chosen Qualisoft’s Qualiware tool because we have worked with the vendor and because the tool supports all the diagrams we use in this text. Most BPMS tools support BPMN, but only a few support the type of stakeholder and scope diagrams we use throughout this book. If the tool is going to be used with a methodology, like the methodology described in this book, then it is good if the tool supports all the diagrams the methodology uses. Our methodology, for example, relies heavily on scope diagrams. We’ve pictured a scope diagram in Qualiware in Figure 15.3. Then, in Figure 15.4 we picture a BPMN diagram. Finally, in Figure 15.5 we show how one might obtain information via a matrix.

Business Process Management Suites

A business process management suite (BPMS) refers to software products that evolved in the past decade. In essence, BPMS products combine features previously found in (1) workflow and document management tools, (2) enterprise application integration (EAI) tools, (3) professional business process modeling tools and (4) new technologies derived from the Internet. Think of a BPMS product as a professional modeling tool with a lot of additional capabilities.

In the 1970s and 1980s IT groups created software applications at the request of departmental or functional units. Thus the accounting department has accounting applications and an accounting database. Similarly, manufacturing and sales each had their own applications, each with its own database. In the 1990s, in conjunction with the emphasis on business process reengineering, companies began to struggle to integrate departmental activities into processes that crossed departmental boundaries. This immediately put pressure on IT to find ways to make it easy for departmental applications and databases to work together and exchange information. The three different types of software tools mentioned above evolved to help facilitate this change.

Workflow tools were created to make it easy to manage processes in which employees processed documents. In essence, an incoming document was scanned and placed in a database. Then a digital copy of the document was sent to an employee’s computer when the employee needed to interact with the document. At a minimum, workflow systems speeded processing by eliminating the time otherwise required to physically move documents from one employee’s workstation to the next. Instead, as soon as one employee finished working on a document and selected SEND the database system would place a copy of the edited document in the queue of the computer terminal of the next employee who needed to work on the document.

At the same time, other software developers focused on building software systems that would manage a diverse set of software application. Rather than try to redesign an application originally designed to work only for one department to work with other applications a whole set of applications were interfaced with a single EAI tool that would move information from one departmental application to another as needed. EAI tools made it possible to operate a number of applications as if they were integrated.

Stepping back from the specific EAI tools we can see that IT tried to solve the problem created by diverse software applications by creating a new application that managed other applications. Similarly, workflow systems sought to integrate employee efforts by providing each employee with a computer and then using a workflow application to manage the movement of work from one computer to another.

The limit on both early workflow and EAI solutions was the lack of a common infrastructure. It was expensive to “wire” diverse things together using the infrastructure technologies available in the early 1990s. All that began to change in the late 1990s when companies discovered the Internet. The Internet was created by the government and used a set of common, open standards. Equally importantly, the Internet was designed to operate over ordinary telephone lines. As the Internet evolved rapidly in the late 1990s a number of technical standards like SOAP and XML were created that made it even easier to interface older software systems and applications with the Internet. That process continues today and most companies have now moved to a service-oriented architecture (SOA) or to Cloud computing, approaches that rely on the latest open Internet standards that make it even easier to integrate applications.

In 2002 a number of different authors and vendors began creating a new type of software that would combine features of the Internet, workflow software, EAI, and process modeling to create a product capable of managing the execution of business processes. In essence, the workflow elements would manage human activities within the process and the EAI elements would manage software applications and databases used during the execution of the process. Everything would be integrated via the Internet and the open protocols created for the Internet. This vision has been variously termed BPM or BPMS. We discourage the use of BPM and opt for BPMS, since BPM is already widely used to describe all kinds of business process work, including much that won’t be incorporated in new software applications.

A BPMS product is a software tool that one can use to develop one or more BPMS applications. A BPMS application is an application that is managed and executed by a BPMS tool. Thus a BPMS application describes a business process and incorporates a BPMS engine that will execute the business process in real time. Imagine a BPMS application designed to manage insurance claims processing. The claims processing process is described by means of a process diagram and can be examined by either the business managers or the IT developers. When an actual claim arrives the application manages the processing of the claim. In fact, the BPMS application is a template of the process, just like any workflow diagram. When the application is asked to manage a specific instance it creates a copy of the template and then maintains the data related to the specific claim in a file in a database. Unlike the template, which shows decision points and multiple branches, a real instance reflects specific decisions and only follows a single path.

If the interfaces are good and the business managers can read a basic process flow diagram the business manager is in a unique position to make or request changes in the business process. The key here is that the actual software applications and databases and the data being processed by employees are all maintained independently of the BPMS application. By simply changing the diagram or the business rules in the BPMS application the business manager can immediately change the way the application functions. In the best case the business manager can make specific changes. In any case the business manager can communicate with IT by describing a process change without being concerned about the underlying implementation details. A BPMS application ensures that business managers and IT developers will communicate by talking about specific processes.

BPMS represents an evolutionary development that has its roots in business process modeling, CASE (computer-assisted software engineering), workflow, rule-based systems, EAI, and packaged applications. Today, vendors who would formerly have positioned their products in one of these categories have repositioned their products and now refer to them as BPMS products.

Gartner estimated the revenue from BPMS sales would reach between $520 million and $543 million in 2003 and estimated that the BPMS market would generate more than $1 billion by 2009. In 2015 Gartner estimated that the BPMS market had reached $2.7 billion. Keep in mind that most of these sales would have been recorded as workflow or EAI sales a few years earlier.

Process Diagrams and BPMS Engines

In essence, a BPMS product is a software package that allows a business manager or business analyst to describe a process and later to modify the process as needed. From a software architectural perspective one could describe BPMS as a new layer of software that sits above other software applications and uses business process specifications to determine when to make use of those other software applications.

The BPMS product includes a process-diagramming interface for the business analyst to use to define the process to be managed and a BPMS engine that generates instances of applications when they are needed and terminates them when they are completed. There’s quite a bit more to it, but let’s start with a simple overview. In Figure 15.6 we picture the two core BPMS elements. One is a graphical modeling environment that allows the developer to create a description of the business process. (In the case of Figure 15.6 the process consists of five activities, labeled A through E.) The other main element is a BPMS engine that follows the script implicit in the process description and manages the creation of instances as specific cases are processed. In effect, a business analyst describes what is to be done, and the engine then “reads” the description whenever the process is executed, invoking each implementation component in order.

Notice that the BPMS system in Figure 15.6 is managing both employees and software applications. In other words, BPMS can combine the ability to manage human tasks (usually called workflow) and software systems (usually called EAI). Obviously, the BPMS system interacts with employees by means of a computer interface, sending requests for information or decisions to employee terminals, waiting for a response, and using the responses to continue executing the process.

Let’s be sure we understand the primary value proposition of those who advocate the use of BPMS systems. BPMS systems should make it possible for managers or business analysts to change how processes work without having to ask IT to reprogram. Some claim any business manager would be able to do this, but that’s unlikely, except in the case where the business manager feels really comfortable with software systems and process diagrams. (Recall that most business managers today do not define processes with diagrams. Instead they use text outlines.)

Figure 15.7 suggests how a business analyst might have used the process design tool in a BPMS package to change a process diagram and thereby automatically change the way the process is executed at runtime. We assume that the same underlying implementation components are still in place and that they function as they did in Figure 15.6. Now, however, the order in which they are invoked has changed. Whenever the process is executed the BPMS engine will read the new diagram and execute the steps in the new order. Moreover, the changes have been accomplished without the intervention of IT developers.

We have pictured the changes in the flow of the process as a change in the arrangement of the activities in the diagram. Some tools allow the user to literally change the way the arrows connect to boxes to effect this redesign. Other tools rely on business rules that state how decisions are made and what activities follow certain decisions. In those cases the manager or business analyst can achieve the changes by simply editing business rule statements. In this case the BPMS engine is executing business rules rather than simply following a workflow description.

The ability of a BPMS product to reestablish links to underlying software components without the intervention of an IT programmer requires a rather flexible BPMS engine. We will discuss the implications of this flexibility a bit later. Meantime, we want to underline what the BPMS package did not do. The BPMS product, as we have defined it, did not create any new components. It simply allowed the business analyst to rearrange the order in which existing components were used. Some BPMS advocates have suggested that BPMS products will “automatically” generate the code needed to provide new implementation functionality. We don’t believe that will be a key part of most BPMS products. On the other hand, some products will allow developers to create code in the tool, and thus to capture business rules that will structure or supplement the functionality of existing software applications.

Before that, however, let’s consider the elements required by a comprehensive BPMS, which so far we have not yet discussed.

What Features Might a BPM Suite Include?

Figure 15.8 provides an overview of one possible architecture for a BPMS product. The BPMS product here would be a rather comprehensive tool or suite.

To simplify our discussion we have divided the BPMS package into four layers. The bottom layer is labeled Middleware/Application Server. Any BPMS product needs to be able to manage accessing and being accessed by other software applications. A few BPMS products handle these functions, but most rely on existing middleware and application server products to provide this support. The most popular platforms are IBM’s Java server, WebSphere, Microsoft’s Windows, .NET, and BizTalk’s server. The leading packaged application vendors offer their own servers to facilitate access to their enterprise resource planning (ERP) and customer relationship management (CRM) applications. Thus, SAP offers NetWeaver, which enables and manages access to many of the SAP modules companies use.

The heart of a BPMS product consists of the engine that manages the runtime execution of business process instances. Most BPMS products offer two or three engines. One engine manages the execution of workflow aspects of a process. At a minimum the engine locates the appropriate employee’s terminal and routes information to and from the employee. Most workflow engines do a lot more. Many, for example, will generate “task lists” for the employee, defining exactly what the employee is expected to do. Others will monitor groups of employees and determine which employee is available or has the skills required for a specific type of task.

A second BPMS engine (the EAI engine) usually manages the calling and coordination of software applications required for the execution of a process. These engines turn other software applications on and off, move data to and from databases, and manage all the associated activities.

A third engine is typically used to manage the maintenance and execution of business rules. When a decision point is reached the rule engine will determine which business rules apply and then examine them to determine the appropriate decision.

Most BPMS products have a history in workflow, document management, business rules management, or EAI. Typically, the vendor has a strong engine to execute the kinds of activities they have historically specialized in, and is working to extend or acquire other engines. Thus, today, if you want to manage processes that are primarily people based you will want to talk with a BPMS vendor with historical strength in workflow. On the other hand, if you want to develop an application that will be primarily software based you will probably fare better if you work with a vendor with a strong EAI background. As the market evolves and mergers continue to occur BPMS products are gradually acquiring strong engines for all different types of applications. Equally importantly, they are gradually rewriting their software so that it is well integrated and so that users can deal with simple interfaces that allow them access to all the different engines and capabilities of the BPMS product.

The third layer includes utilities that are required for the development of a BPMS application. The business analyst needs a development interface that he or she can use to describe the process to be managed. The business manager needs an interface that will make it easy to modify the application as the process changes. Both need a modeling environment that provides a graphic overview of the process that will be executed when the application is used. Similarly, both need an environment that will make it possible to capture data as the process is being executed so that the business manager can determine how the process is performing. In addition, many tools provide a spreadsheet-like interface, so that everyone can see and edit the business rules that are used in the process. In the worst case the BPMS product has been assembled from many different, earlier products and there are a variety of incompatible interfaces that the manager and developer must master. In the best case the vendor has created common interfaces that let the analyst or manager move easily and smoothly between the various elements that must be coordinated, managed, or changed.

Most early BPMS tools limited themselves to the three layers we have just described. Currently, a number of BPMS tools also include knowledge elements that make it easier to create specific types of business process applications. Let’s say you want to create a BPMS application to manage the day-to-day execution of a bank process. In that case a BPMS tool that came with sets of business rules typically used for major bank processes, or with workflow diagrams that describe typical bank processes, would save you time as you sought to create your bank application. Similarly, a BPMS package that provided the Supply Chain Council’s SCOR framework of process and performance measures would make it a lot easier to quickly create a supply chain management system. Predictably, as BPMS products become more mature, some BPMS vendors will specialize in specific industries and include sophisticated packages of knowledge elements with their products.

Most BPMS products being sold today provide a limited type of monitoring. They record events as they occur, summarize that information, and provide data on a manager’s interface. This kind of monitoring is appropriate for supervisors who have immediate responsibility for the specific process. Let’s assume we were using a BPMS application to manage a call center, assigning incoming calls to operators according to their availability. In this case the BPMS system would let the supervisor know how many calls each of the various employees handled in a given time period.

More sophisticated monitoring requires quite a bit more technology. To create an executive dashboard that would provide useful information to a VP responsible for a large business process, for example, we would need to combine data from specific processes with information from many other sources. We might also want sales data, data about recent customer surveys, or data from suppliers. All these data would need to be accumulated in one place—in a data warehouse, for example—and then they would need to be analyzed and filtered so that only summary data were provided to the senior manager. The analysis and filtering operations usually rely on data-mining systems and on business intelligence (BI) techniques. Only a few BPMS products provide the additional technologies to support data warehouse, BI, and executive dashboards (Figure 15.9).

BPMS, SOA, and the Cloud

A BPMS product could use any of a variety of different infrastructure techniques to link to software applications. Historically, each of the EAI tools created their own engines to manage access and linkages. In the last two decades, however, the rapid rise of open Internet standards has focused most developers on a new approach that is usually termed service-oriented architecture (SOA).

SOA depends on the Internet and a collection of Internet protocols, including XML, SOAP, UDDI, and WSDL. It depends on organizing software applications as software components that can be called via the Web. A manager considering how his or her company can outsource business processes while still maintaining control over the outsourced processes doesn’t need to know any of the details. He or she simply needs to know that SOA is a cost-effective way to organize and integrate distributed software assets.

BPMS does not require SOA, but SOA certainly requires BPMS. Services don’t make any sense without the context that business processes provide. Conversely, the runtime automation of a business process assumes an underlying layer of services, middleware, and, ultimately, software components, and SOA currently provides the most cost-effective way to organize that infrastructure. Even human-focused BPMS systems designed to automate the work of teams of employees still assume the existence of the middleware and software needed to send information to employees’ desktop PCs and to store the results in appropriate databases.

In the last few years BPMS vendors have begun to focus more attention on the Cloud than SOA. The Cloud is a term that describes computing architectures in which all or most of an application and all the data for the application is stored on a database that is accessed via the Web. Thus, if one wants to use IBM’s BlueWorks one does not need to load the software on one’s mainframe or laptop. Instead, one downloads the program from an IBM server (the Cloud) whenever one wants to use it. If one creates an application via BlueWorks the application code and any data created when the application is executed are stored on the IBM server. This saves the analyst, developer, or user from needing to have the software on a computer—and also means that the application can be run on a small machine, such as an iPad or perhaps even a smartphone. It also guarantees that the software program the user accesses is always up to date. Access, of course, depends on the speed of one’s Internet connection, but that problem is rapidly being resolved, especially in large organizational environments.

The hope is that, eventually, businesspeople will be able to focus on the business process layer and make changes there, using BPMS tools that will available anywhere, and will more or less automatically rearrange activities on underlying layers. The reality today, however, is that most companies are working to create systems that integrate all these layers and that both BPMS developers and SOA developers need to worry about all aspects of the architecture. Thus most BPMS efforts involve teams of business and IT people working together.

Choosing a BPMS Product

Figure 15.8 provides one way to think of the different capabilities of a BPMS product. In this case we picture a “radar diagram” that we have used to evaluate BPMS products. We begin by creating one branch for each feature set that is important to us. Along each branch we indicate the criteria we use to determine if the product lacks the feature, has some of the desired capability, or implements the feature in the best possible way. We make notes about the uses a particular company wants to make of the BPMS product to help users think about what’s most important to that particular company. Then we map each product we are considering onto the radar diagram. Using dotted and dashed lines, as well as shading, it is easy to map and compare several applications.

The shaded area in Figure 15.8 suggests what some particular company decided it absolutely needed in any BPMS product it considered. The two lines show how two specific BPMS products were evaluated. In this case neither provided the minimal functionality that the company felt it required. We provided this example not to provide a definitive way of evaluating BPMS products, but to suggest how to approach the problem, and to underline the fact that the acquisition of a real product will involve a series of compromises.

Some Leading BPMS Vendors

Without trying to be comprehensive here’s a list of the BPMS vendors that we keep running into at shows, where we have either discussed their products directly with them or have talked to companies that have used those products to develop a BPMS application.

The three vendors that seem to have the largest presence in today’s market are IBM, Pegasystems, and Software AG. The other vendors on this short list are major players with a slightly smaller presence:

• • Appian (Version 6). Appian is one of the smaller players in the BPMS space and has a reputation for being relatively easy to use.
• • HandySoft (BizFlow). Another small vendor that has been around since the beginning and has a good reputation.
• • IBM (Business Process Manager Version 7 and WebSphere Operational Decision Management Version 7). IBM is the largest player in the BPMS market and has acquired a wide variety of tools. After a period of consolidation IBM is now offering a relatively integrated and consistent BPMS package.
• • OpenText (a variety of products). OpenText has also acquired a variety of tools, but has a way to go to integrate them.
• • Oracle (Business Process Management Suite). Like IBM, Oracle has acquired a variety of earlier vendors, but has a way to go to integrate everything. Oracle’s overall commitment to the BPMS market seems to wax and wane.
• • Pegasystems (PegaRULES Process Commander Version 6). Pega started life as a rule-based expert systems vendor and morphed into one of the strongest BPMS players. Those who like a rule-based approach to software development tend to like this tool.
• • Software AG (webMethods BPMS Version 8). Software AG came to BPMS late with its acquisition of webMethods, but followed that with its acquisition of IDS Scheer’s ARIS, thus catapulting itself into a leading position in the process software market.
• • Tibco Software (a variety of tools). Another major vendor that has acquired a variety of tools and has yet to integrate them as well as it might.

Beyond this short list of vendors we could easily add another 20 names of vendors who are active in the BPMS space. Some are focused, like the vendors above, on selling to IT groups, but others are focused on vertical markets or on selling to business groups who are interested in manager-controlled process development. And new, small vendors keep popping up.

The changing nature of the software market is one cause for the continuing emergence of new entrants. The early BPMS tools were all based on client-server designs. A few years later vendors began to shift to SOA designs, and recently they have shifted to Cloud designs. In a similar way, the BPMS market has shifted its focus from process flow to business rules to analytics. Each shift creates an opportunity for new vendors to rush in offering new products. The larger vendors acquire the best of the new entrants and begin to incorporate the new technologies in their already complex products, and meantime some of the new vendors grow rapidly because they offer a particularly good approach to the latest problems. As we said, the BPMS market has been and remains very dynamic.

In addition to all the very real transitions in the market analysts have introduced some pseudo transitions that don’t amount to much. Thus, for example, Gartner would have readers believe that there are now BPMS tools that focus on case management and “intelligent BPMS.” Given that there is next to no market for “intelligent BPMS,” this is nonsense. The reality is that the BPMS market is relatively small and every vendor is going after every opportunity it can find. The reason Gartner is now talking up case management and “intelligent BPMS” has more to do with Gartner’s marketing concerns than with the realities of the BPMS market.

For many reasons the BPMS market continues to develop and will grow more complex in the years ahead. The market for BPMS products is largely gated by just how mature the BPM of user organizations is. As those organizations continue to learn more about the process-centric approach and to adopt it, they will in turn look for integrated BPMS products and the market will continue to expand.

Creating a BPMS Application

There is to date no widely accepted methodology for BPMS application development, although some vendors offer their own suggested procedures. In part, this is because BPMS is new and few companies have developed enough BPMS applications to have a good understanding about what works best. In addition, as we have suggested, there are in fact a number of rather different products all going under the BPMS label. Thus the approach one might follow to develop a human-centric BPMS application (workflow) is different from the approach one might follow to create an integration-centric BPMS application (EAI) or a decision-centric BPMS application (rules based). Some companies model and redesign their processes using conventional business process modeling tools and then move the application over to a BPMS environment for runtime execution, while others develop their own BPMS tools directly. There’s little consistency and no one has enough experience.

Stepping back from specifics we can offer one very important piece of advice. Don’t start a BPMS project until you are sure that the process you intend to manage using a BPMS application is already running as you want it to run. In other words, do not try to combine a process redesign project with a BPMS application development project. Both types of projects are demanding and require different skill sets, and combining them is a recipe for failure. Redesign or improvement can be done using the techniques we described in Part II of this book. Once you have processes you are happy with consider setting the process up in a BPMS environment for day-to-day management and execution.

Getting a BPMS application up and running is an IT implementation project. The problems we have heard about are classic software development problems and have little to do with process work as such. Companies have had trouble getting the infrastructure right. Companies have developed applications in one tool and then realized that the application wouldn’t scale to support the number of transactions they wanted to run on a daily basis, and so forth. As we have suggested, companies are still learning about BPMS, so don’t attempt to automate an application that you can’t afford to have fail. Get some experience with BPMS before you attempt anything too challenging.

With all these qualifications in mind, imagine a world in which your major business processes are defined using process modeling and you could literally watch them flow through the different activities your application was designed to monitor. You could notice bottlenecks as they began to occur, you could change business rules, and watch how they changed the activities that were taking place. BPMS offers a world in which processes are more central and better managed than ever before. It offers a world in which managers can observe the work being done and change the process as needed in something close to real time. They are a solution to lots of the demands that today’s managers face. Leading companies are investing in BPMS because they see its potential and want to use it to gain competitive advantage over their rivals. In a decade’s time we expect BPMS applications to be as widely used as ERP applications are today. The trick in the meantime is to plan your transition to this technology.

Notes and References

We have published an extensive article on how to evaluate process modeling tools. It is available at http://www.bptrends.com (search for Evaluating Process Flow Modeling Tools).

IBM’s BlueWorks Live is available at http://www.ibm.com. Readers can download a free trial version if they want to experiment with it. It is part of IBM’s BPM Suite, which we will consider in more detail in the next chapter, but it is sold separately so it also competes in the modeling tools market. We could have used any of a dozen tools to illustrate how a modeling tool works, but we chose this one because it is one of the leading products in the market and because readers can readily get it to examine if they wish.

We picture a screenshot from Future Tech System’s Envision process modeling tool that supports the various diagram types described in this book—including stakeholder and scope diagrams and BPMN diagrams. Moreover, the tool is repository based so once information is entered for one diagram it can easily be reused. More information about Future Tech System’s Envision is available at http://www.futuretec.com.

We used a screenshot from Fluxicon’s Process Mining tool to illustrate the use of process mining. More information on this tool is available at http://www.fluxicon.com also check http://www.BPTrends.com for articles by Anne Rozinat.

A good book on process mining is van der Aalst, Wil, Process Mining: Discovery, Conformance and Enhancement of Business Processes, Springer, 2011.

BPTrends has written a report that describes the popular elements of BPMS products. The report is free and available at http://www.bptrends.com (search for Evaluating BPMS Products).

A list of many popular and open-source BPMS tools is maintained by the International BPM conference group. It is available at http://bpm-conference.org/bpt-resource-management/.

There is ambiguity about the phrase business process management. Executives tend to use it in a generic sense to refer to managing processes. People in the workflow and XML business process language area often use BPM and business process management as synonyms for BPMS to refer to systems that automate business processes. Also keep in mind that some people will use workflow or EAI as synonyms for BPMS.

Dumas, Marlon, et al., Fundamentals of Business Process Management, Springer, 2013. A book providing a lot of detail on the functions and capabilities of BPMS tools.

Smith, Howard, and Peter Fingar, Business Process Management: The Third Wave, Meghan-Kiffer, 2003. This book kicked off the current interest in BPMS tools and applications. It’s a bit over the top, but it presents the case for BPMS with lots of enthusiasm.

Khan, Rashid N., Business Process Management: A Practical Guide, Meghan-Kiffer, 2005. Of the books published that have sought to explain BPMS products this is the one I think offers the most practical and straightforward presentation.

White, Stephen, “Using BPMN to Model a BPEL Process,” BPTrends, March 2005. This paper on trends in business processes walks us through the way BPMN can be used to generate BPEL, the language underlying some BPMS products.

Owen, Martin, “BPMN and Business Process Management,” BPTrends, March 2004. This paper on trends in business processes discusses the use of BPMN for BPMS development.

Rosen, Michael, “BPM and SOA: Where Does One End and the Other Begin?” BPTrends, January 2006. Mike Rosen has written a series of articles on trends in business processes describing the relationship between BPM and SOA. This is the article where he introduced the diagram depicted in Figure 15.10, but all of the articles are worth reading.

There are no books that really describe a methodology for BPMS development. Derek Miers has published two papers on trends in business processes that suggest what such a methodology might look like:

Miers, Derek, “Keys to BPM Success,” BPTrends, January 2006.

Miers, Derek, “Getting Past the First BPMS Project,” BPTrends, March 2006.

Chappell, David, “Understanding BPM Servers,” BPTrends, January 2005. This is a nice summary of how Microsoft is approaching BPMS with its BizTalk Server.

The International Conference on Business Process Management is a yearly event at which researchers gather to explore the inner workings of BPMS technologies. Each year the conference publishes its proceedings via Springer under the general title Business Process Management. If you are interested in technical issues involved with BPMS these technical papers can be useful.

The web address of the Workflow Management Coalition (WfMC) is http://www.wfmc.org. The WfMC was founded in 1993. It’s a consortium of major workflow users and workflow vendors. The WfMC meets frequently to discuss key workflow issues and has developed a number of workflow standards.

Moore, Geoffrey A., Crossing the Chasm, HarperBusiness, 1991.

A search for BPMS on http://www.bptrends.com will generate a large selection of articles. This field is changing very rapidly and new articles are being published each month.

Swanson, Keith D. (Ed.), Mastering the Unpredictable, Meghan-Kiffer, 2010. A good introduction to case management and the evolution of tools designed to deal with dynamic processes.