Managing Rules (and Achieving Agility) with Business Process Management

he pressure is on for IT to deliver applications that can change on a dime?evolving as quickly as the business evolves even in the face of uncertain requirements. To address these challenges, new programming models?such as extreme programming and iterative development?have emerged. The primary goal of these new models is the same: shorten development cycles with more constrained requirements and then enhance the requirements under the same model. At the same time, new technology architectures are emerging around the ideas of services and processes. Service-oriented architecture (SOA) and business process management (BPM) are gaining momentum as they too hold the promise of increased agility.

Unfortunately, in many cases, the promise of agility is not being delivered. In the face of reduced resources and an ever increasing backlog of requests, many IT organizations are struggling to keep their heads above water let alone deliver agility. The problem is not that developers aren’t up to the task technically?it is that the most common application development (and enhancement) models don’t work in the modern business environment.

Think about it. Traditional application models are built around gathering requirements from users, finalizing those requirements, implementing them, and then using a structured change order approach with structured release cycles to make adjustments. These models cannot succeed in an environment where business users:

  • Cannot define their requirements concretely?they change at a moment’s notice (often not because the business user wants to change them, but because the business environment is forcing the change).
  • Want to change the system, even before it’s deployed.
  • Request that things be changed out of regular cycles due to urgency.
  • Cannot afford the extra design time and planning to create more parameter-driven systems that would enable them to tweak the systems without requiring help from IT.

In fact, the biggest source of this tension is the increasing focus on “processes.” Everyone seems to want systems that automate and improve business processes, whether embedded in traditional applications or as a custom system focused on one process area. But processes are frequently reactionary, and that’s wherein the trouble lies.

Processes are inherently volatile. Most processes became part of the business environment not through careful planning, but in reaction to a need to get things done. Processes typically flow across systems, filling the gaps between them and the people in the company. And they change on a regular basis to address new customers and new business situations. Often those changes are not as simple, to a developer, as changing the fields returned from a database query. Instead, they may be about changing the order in which things are done and who does them. In fact, the focus on processes has given rise to the market area known as BPM.

BPM is one of those “TLAs” (three-letter acronyms) that mean different things to different people. Some people consider BPM to be purely a business approach?it’s all about the business organizing around their key processes. Others consider it technology?software that enables processes to be modeled, automated, managed, and optimized. The reality is that BPM is actually a combination of both of these areas and one more: BPM represents a new way for IT to partner with business teams to deliver agile process applications. In other words, when properly utilized, BPM can help prevent issues involving changing requirements from the bulleted list above from negatively impacting your project. Understandably, this last point is the key to broad BPM success. And it’s a key that has been largely ignored to date.

Some organizations gravitated to it through visionary leadership or luck and have been very successful, implementing lots of high-value processes that are highly adaptable. Others have implemented BPM under more traditional models of IT and business interaction and had project failures or limited success. And the effort to change has been as great, or greater, than with traditional applications. To understand the challenges, a closer look at BPM technology is required.

Editor’s Note: The author is an employee of Ultimus, a vendor of business process management products. Information about Ultimus BPM is provided herein as an example of BPM benefits. We have selected this article for publication because we believe it to have objective technical merit.

BPM: Facilitating Agility
BPM technology is focused on managing the lifecycle of a business process through software. This involves creating a process model, implementing that model as a process application where work flows between people and systems, managing the running application, and optimizing the application while it’s being used?either to make core process improvements or to adjust to changing business conditions. Most BPM solutions support involvement by business users at various phases of the lifecycle?the most common being to enable business users to develop the initial process model that is then passed to IT for implementation.

Some BPM systems provide the ability to push much more of the process lifecycle activities out from the development organization and make the business user more agile. A great example of this is rules. In business processes, rules are most commonly used to manage the sequence of step execution and task assignments.

Rules can be designed for known business processes. For example, a company has these known situations for its business process:

  • Platinum-level customers receive the fastest review of distributor return merchandise requests (RMRs), regardless of whether items are under warranty or not.
  • If the merchandise is still under warranty, the RMR will be processed through a standard review. Otherwise, it will be processed through an “exception” review.
  • RMRs received from customers in regional office areas will be processed by the company’s local offices.
  • If the RMR is rejected, the ERP system will be updated to reflect to the distributor that the RMR was denied.

Codifying these processes as rules ensures consistency and efficiency of company policies. Today there are WYSIWYG applications that greatly simplify the creation and modification of such rules. This also allows for processes to be adapted in real-time by addressing changing business conditions quickly and easily. The following is an example of how to create and adjust rules within the Ultimus BPM suite.

Editor’s Note: The author is an employee of Ultimus, a vendor of business process management products. Information about Ultimus BPM is provided herein as an example of BPM benefits. We have selected this article for publication because we believe it to have objective technical merit.

Rule Example:
This rule will ensure that “Platinum” customers receive an expedited review, regardless of the warranty status of the products they are returning. To create the rule:

  1. Create an alias to represent the “customer care level.” Call this alias Customer Status Level.
  2. Create a new rule by right-clicking on the Completed event node in the Get Cust and Item step, then select Add Rule. The new rule will automatically display in the Rule Editor pane.
  3. Drag the new alias Customer Status Level into the Rule Editor pane and place it on the rule.
  4. On the other side of the comparative operator, double-click, and then type Platinum. This creates an expression that states, “If Customer Status Level is equal to Platinum.”
  5. Drag the action Activate Step to the termination point on the rule, then release the mouse button. Upon release, the Activate Step dialog box appears (see Figure 1).
  6. From the Step combo box, select the Expedited Review step. This creates a rule that states, “If Customer Status Level is equal to Platinum, then activate the step Expedited Review” (see Figure 2).

  7. Figure 1. The Active Step dialog appears.
     
    Figure 2. The Expedited Review is enabled.

Rule Exceptions
Some of the rules will be used all of the time, some may only be considered in unique circumstances. But invariably they change frequently. Often, the change may be as simple as “skip this review step for a special customer.” Invariably, special business conditions drive the need to change the rules, so empowering business to take more responsibility in managing the change can be good for both IT and business.

For example, imagine that the company in question has a customer (Worldwide Cable) that will be purchasing a high volume of merchandise for a large contract that will be fulfilled within 30 days. They would like all RMRs submitted by Worldwide Cable during the contract period to be processed rapidly to minimize delays for the contract. Therefore, Worldwide Cable, which normally has “Gold” customer care status will be receiving “Platinum” customer care status for a period of one month.

Figure 3. Change the properties of the rule so that it expires in one month.

To create this rule exception:

  1. Create an alias to represent the customer name of the RMR submitter. Call this alias Customer Name.
  2. In the Completed event node of the Get Cust and Item step, create a new rule. To do so, right-click on the Completed event node in the Get Cust and Item step, then select Add Rule. The new rule will automatically display in the Rule Editor pane.
  3. Drag the new alias Customer Name into the Rule Editor pane and place it on the rule.
  4. On the other side of the comparative operator, double-click, then type Worldwide Cable. This created an expression that states, “If Customer Name is equal to Worldwide Cable.”
  5. Drag the action Set Alias Value to the termination point on the rule, then specify to set the alias Customer Status Level to “Platinum.” This created a rule that states, “If Customer Name is equal to Worldwide Cable, then set the alias Customer Status Level to ‘Platinum’.” This rule will be named Worldwide Cable Customer.
  6. To allow Worldwide Cable to have “Platinum” customer care status for one month, right-click on the rule in the Rules pane and select Properties. In the Enable Properties section (see Figure 3), specify a period of one month. This ensures that the rule exception will automatically expire within 30 days without requiring human intervention.
Author’s Note: For this example, the ERP system will not be changed to make Worldwide Cable a “Platinum” customer for 30 days; this is being handled entirely within the process for a few reasons:

  • This is the only Ultimus process for which the customer care level is relevant.
  • The ERP system is complex, and making this change in the ERP system would require a large amount of time, effort, and financial resources.
  • Typically, ERP systems are set up to only handle changes to customer status level for a period of 12 months or greater. Adjusting the ERP system to handle more granular status level time period changes would require extensive customization.

Reducing the Burden on IT
BPM systems that support distributing responsibility for managing running processes provide an opportunity for IT to reshape its relationship with business, accelerate deployments, and eliminate from their request backlog a number of items that are neither exciting nor challenging for developers. To capture that opportunity, it is critical to understand the key components of a business process, identify the most logical resource to manage that component, and assemble a team that involves business users and IT personnel to execute the activities. Ideally, the BPM environment should be intuitive enough for business users to create and modify rules.

On the other hand, Web Services development and SOA can lead to an agile business, but not if the IT developer has to constantly make code changes on his own to process items like rules, roles, and basic step definitions. If that’s the case, then a business is only as agile as the developer’s list of “to do items”?the shorter the list, the more agile the business. By giving business users control of the right parts of processes, a business can achieve agility (and a more innovative and interesting “to do” list for the IT developer all at the same time). These tasks are not exciting for the developer, but if pushed to the business user, they can make the business more agile.

In summary, IT is under tremendous pressure to provide technology that supports continuous business change. BPM technologies can enhance the ability of IT to deliver on that goal while also improving alignment with business. When looking at BPM technologies, it is critical to assess the ability of the systems to support distributing responsibilities across a BPM team with skills that range from developers to business analysts to business sponsors. Once in place, the identification of who will be responsible for what aspect of process implementation and change becomes a pure business decision, driven by resources and goals, without technology constraints (e.g. “Business should manage the rules, but they are too complex and embedded in the process code, so we’ll have to have the development team manage them.”)

Organizations that have operated under this shared model have seen tremendous benefits including delivery of high business value, reduced backlog, faster, lower risk deployments, and improved stature of IT within the organization.

Share the Post:
Share on facebook
Share on twitter
Share on linkedin

Overview

Recent Articles: