The Wizardry of Business Process Management - Part 4




Part 1 of this blog series started a lengthy discussion about the value proposition and parts-and-parcels of business process management (BPM), with an ensuing focus on Pegasystems (also known as Pega) as one of the leading BPM suite providers. Part 2 then analyzed in depth the vendor’s ability to help business users capture (and then realize) business objectives and intent, while Part 3 focused on Pega’s ability to automate programming and execute actual workflows at customer organizations.

This part continues with more of Pega’s value proposition and its “BPM secret sauce” ingredients, such as a so-called “servicing backbone” for service organizations. 

Showing a Servicing Backbone

Customer service typically moves service requests through many systems and many hands in departmental silos (e.g., sales, service, operations, product development, administration), but not always as planned. Inevitable business changes create execution gaps between the ideal service and the actual service, which alienate customers and aid the competition.

Furthermore, there are layers of business operations within these functions that further fragment the organization into a collection of islands. This creates additional seams and chasms that customers, internal staff, and partners must tediously navigate to get business done.

Employees and customers are in the difficult position of having to navigate this dispersed environment, by bouncing back and forth (a “swivel chair” phenomenon) between various computer screens, organizations, systems, and manual procedures. Most serious are the explicit execution gaps where the automation and infrastructure haven’t kept pace with what management wants to be done. In other words, these are the all-too-common situations where manual procedures or training must try in vain to fill the gaps.

For example, Pega often sees gaps in the opening of a new account process and in implementing strategies for customer retention and cross-selling (i.e., deciding which customers should get which offers and then ensuring the right follow-up). There are also often the gaps caused by difficulties in introducing new products, gaps in ensuring that complicated proposals are subject to the right compliance procedures, gaps in fulfilling customer-specific commitments or promises, and so on and so forth. These execution gaps further exacerbate the chasms between the departmental silos.

Initiatives to fix these execution gaps (process exceptions) tend to require adding staff, ad hoc IT solutions, or both. With traditional “stop-gap” approaches to throw in more people and heterogeneous IT tools, a servicing infrastructure proves to be prohibitively expensive and highly disruptive in terms of system downtime, replacement costs, poor customer service, and many other related “moment of truth” nightmares. Consequently, business users get bounced around in these gaps struggling to get to the right outcome.

To make a distinction, execution gaps due to process exceptions can be reduced with automation using better (more detailed) policies and rules, and can be managed using a good people process. But there is another set of execution gaps (referenced above as “departmental silos”) that need smarter integration, at the data, business logic, or presentation layers, to cross the silo boundaries. These are also addressed by enterprise-class BPM suites like Pega's.

Compliance and control are particularly serious issues, since in this ad hoc environment there is no way for management to dig in and really see what is happening until it is too late, long after the work has been done. In fact, this ZDNet blog post talks about the nine worst business processes that Pega has identified, presumably based on the difficulty of capturing and automating them, starting with governance, risk management, and compliance (GRC) .

The execution gaps (exceptions) are the worst business problem of all, and everyone would like to build an ideal scalable service infrastructure, where things work the way they should. Thus, let’s explore how organizations with complex operations could apply technology to address and prevent execution gaps. To that end, agile service organizations first target critical gaps to bring quick value by improving processes and decisions, while guiding users and customers through the gaps.

Thereafter, building on the benefits and experience achieved in filling the initial process gaps, agile organizations continue to put a non-invasive layer in and around their IT infrastructure. The idea is to shore up the weak spots and smooth out the rough ones. The goal is to also leverage the existing IT assets by incorporating them as services (implicitly inside the process or explicitly in an SOA framework). This “wrap and renew” initiative allows the organization to extend the infrastructure by creating a smart layer of business rules and processes that has the intelligence to make key decisions.

As explained in Part 2, the system should understand the business purpose (intent) of each interaction and thus perform the work to achieve management objectives based on best practices and the most current information. In this setup, people are not asked questions the system can figure out itself. Neither are business users forced to go through steps that are not relevant to a valid outcome.

With adept BPM solutions that accommodate change and with business intent-driven user experiences, companies can close the gaps and increase business agility, efficiency, and competitiveness. Rather than attempting a “big bang” undertaking, companies should implement improvements to one customer issue at a time, starting with any business process that needs improvement (e.g., open a new account, charge a dispute, detect fraud, increase credit line, missing a payment).

Handling Complex Organizations? A Piece of (Situational Layer) Cake!

For the reasons explained in the previous paragraph, Pega frequently sells initial BPM software licenses to target accounts that are focused on a specific purpose or area of operations, rather than selling large enterprise-wide licenses. A primary objective of this strategy is to have its customers quickly realize business value from Pega’s software.

Once a customer has realized this initial value, the vendor then works with that customer to identify opportunities for follow-on sales. The sales process for follow-on sales is often shorter as a result of Pega’s established relationship with the customer. Typically, organizations can automate their first process in 90 days, and the next process can be delivered in even less time.

This is how sophisticated service companies can create an ideal service infrastructure (servicing backbone) in small manageable chunks. With every process they create or improve, they should build for (necessary future) changes. Namely, while every process is specialized for a particular circumstance, the ability to reuse the components from previously built processes enhances the company’s foundation for agility.

Making situational rule selection work requires the right structure for organizations to adapt and innovate.  Pega allows organizations to add “specialized” layers of instructions to their repository of rules (RuleBase, in Pega's lingo) by recording just what will be different in specific situations. This is modeled to match the way people think, and makes the system easier to understand and instruct.

For example, a business may have a company-wide standard (or baseline) way of processing orders. But when an order is for a key customer and the product is out of stock, the company may want to do something special. Or, if it is a first-time customer in a certain region, the organization may have special customer satisfaction checks it wants to run.

Pega’s flagship SmartBPM Suite handles these situations by layering-on specializations, i.e., adding personalization differences without having to go back and manually weave revisions (pesky and dangerous software versioning) into the corporate standard. Users can specify how their processes, decision rules, and data sources will work just as they would do if they were explaining their business policies to a new employee. The SmartBPM engine determines which set of processes, rules, and data sources apply best in every situation.

To illustrate, the figure below shows an example of a hypothetical global company with specialized needs in the US, Canada, and Europe. The SmartBPM suite with the PegaRULES Process Commander (PRPC) rules repository is the supporting BPM solution, whereby a baseline BPM application with enterprise-wide best practices has been built on top of the rules database.  There would be a number of individual RuleBase entries that define standard corporate processes, decisions, and data sources.layer.png

The next layer might then contain specializations representing differences between North America and Europe. This “layer cake” can evolve to handle additional business differences, whereby new versions can then be layered on top to contain only the rules that describe differences (while the unchanged characteristics are inherited from lower layers). For example, they could add French specializations for the appropriate portions of Canada and some other idiosyncratic factors to roll out a pilot project in Los Angeles.

Incidentally, Pega’s SmartBPM Suite lets users easily pilot (i.e., test or simulate) new situations to understand options and validate expectations. Piloting can be conducted in terms of customer segments, regions, product lines, time zones, channels... you name the factor or dimension. The ability to quickly and safely pilot proposed changes allows an operation to validate new concepts such as cost-saving measures or tailored product offerings before investing in the entire solution suite.

SmartBPM’s distinct Layered Situational Rule Selection architecture allows easy pilots and what-if analyses even in quite complicated, global environments. To add a pilot project, the administrator would creates a new layer for a part of the operations, designates the appropriate users (or channel) and the specialized rules they should use. Administrators can also limit the application of those rules to certain customers or products.

In this way the deployment is managed by the system, and training is minimized because Pega’s layered situational architecture will guide users through new process variations. Once the company has been able to verify and fine tune the results, a simple instruction deploys the pilot project across the operation.

Because the original definitions are still intact, the system allows a roll-back (reversal) if ever needed by simply instructing PRPC to ignore this particular layer. This piloting capability gives managers the ability to compare real outcomes, costs, and user satisfaction, and to also learn by doing.

Pega’s patented “Inherited Rules” multiple inheritance technology is at the heart of this Situational Layered Rule Selection architecture. The engine reconciles the “deltas” (differences) so that every situation gets the optimal “stack” of rules, processes, procedures, policies, etc. The “layer cake” versioning makes it easy to combine, re-use, specialize, and yet still inherit rules and attributes by astutely using Java objects and classes in PRPC.

There are vast potential benefits in enterprises being able to easily discern what is unique for different constituencies, and in not falling into the trap of dangerously changing and affecting the “baseline” foundation. This approach lets users layer on the differences and the resulting “delta-based” model works the way that people actually think. This method makes it easier to define, understand, and evolve (i.e., plan for all situations and circumstances).

Declarative vs. Procedural Programming? Why Not the Best of Both Worlds?

At the end of the day, if I have to recap Pega’s differentiation from most of its BPM competitors in two concepts, those would be 1) unified business rules and processes, and 2) the declarative modeling capability. Both concepts aim to significantly reduce the need for manual programming (coding).

Declarative modeling means that business people can set the business goals while the system figures out how to execute processes (based on Pega's Solution Frameworks that offer pre-built configurations and industry best practices and benchmarks, as mentioned in Part 2). Business users can “directly capture objectives (DCO)” in business user-friendly metaphors and tools as follows:

This method is in sharp contrast to the still-prevailing approach of deploying a patchwork of BPM modules in a non-declarative modeling manner. In this manner, disparate applications have to be built to manage policies and procedures. Business policies must be “coded” as technical business rules in a business rule engine (BRE) or in some programming language like Java. In addition, application programming interfaces (APIs) must be defined or calls performed at fixed, specific places in the process to use the rules.

On the other hand, visual process models must be captured within a BPM suite, or in modeling tools like Visio, Eclipse’s M1, IDS Scheer ARIS, etc. Alternatively, processes can also be programmed within an enterprise content management (ECM), enterprise application integration (EAI), or enterprise service bus (ESB) solution, or in Java procedural modeling. Also, the process is often imported and converted into an execution environment before being refined and programmed, so the original diagram becomes a fossil artifact of the development, no longer representing the actual executing process.

Moreover, a UI has to be mocked up in tools like Microsoft Word or Paint, and then programmed in HyperText Markup Language (HTML), JavaServer Pages (JSP), or Portal Software (now part of Oracle), etc. Logically, the integration of all these components must also be accomplished with lots and lots of additional code.

And since each layer or component comes with its own data model, the composite BPM application has to be cobbled together with yet more code. This means that changes to one component will normally entail interdependent changes to all other components. “Code, baby, code!” would be the unfortunate tagline here, while the necessary software testing and documentation will likely not be integrated either.

Enter Pro-Dex

To eliminate the above shortcomings, Pega offers the trademarked Pro-Dex concept, i.e., the marriage of Procedural and Declarative execution to deliver the full power of business process automation (BPA), thus boosting customers’ agility and return on investment (ROI). Pro-Dex mirrors the way that business people think and manage their business. Namely, people naturally use these two approaches (i.e., procedural and declarative) constantly during every business transaction by seamlessly weaving together processes and overarching policies.

Let’s then look at how SmartBPM provides the “smart DNA” needed to fill the process execution gaps. Companies typically start by incorporating the procedural thinking that drives processes throughout businesses. Business people routinely define and evolve their businesses through procedure documents, flowcharts, instruction manuals, etc.

Nearly all programming languages (e.g., COBOL, C++, Java, etc.) are procedurally based. The “Pro” in “Pro-Dex” describes how Pega’s Process Commander rules engine captures and automates procedural elements using friendly forms and user constructs that support agility.

But businesses are also driven by declarative process executions. The “Dex” in the “Pro-Dex” approach is accomplished by declaring how we want things to happen, without necessarily weaving each declaration into every process.

Businesses users set (declare) targets and goals that guide and prioritize business processes. As described earlier on in the situational layer cake, using “big-picture” understanding, users might want to override some policies to supplement standard processes with differences they want to consider.

They might want to declare that the company wants different practices and offerings for a particular customer, for a particular product, in a particular region, and so on. Alternatively, the company might want to identify what might make a transaction suspicious for fraud, without having to laboriously weave the criteria into every situation.

Certainly, there are logic programming languages that incorporate declarative constructs. Some of us may have heard of PROLOG, LISP, Smalltalk, and other rules engines coded into specific applications.

I might not be aware of every BPM vendor’s offering in the market, but I think that currently only Pega's rules engine marries this declarative execution seamlessly with the procedural aspects of PRPC. A unified Pro-Dex framework figuratively represents the double helix structure of any business’ "DNA code." Having a system that only supports one of these two approaches well, or that makes programmers try to painstakingly figure out how to get the "Pro" and the "Dex" sides to work together can hardly ever provide optimal agility and power.

Forget Not About a Flexible and Open Architecture

As said in Part 1, the integration-centric service oriented architecture (SOA)-based middleware providers have often been accused by true BPM suite providers like Pega of primarily targeting IT departments to try to sell BPM as a matter of service orchestration. These SOA integrators are sometimes seen as the BPM party “gate-crashers,” since the true value of BPM should be realized by empowering business users.

Still, Pega is more than aware of the SOA, Web-oriented architecture (WOA), and event driven architecture (EDA)-based software architectures being at the very heart of BPM (remember the Tin Man from Part 2?). Thus, Pega’s software architecture is layered, model-driven, and standards-based to leverage (fit into) existing IT investments. The product supports typical application programming interfaces (APIs), including extensible markup language (XML) and electronic data interchange (EDI) adapters, but in most implementations, integrations to both legacy and SOA-based systems require no coding, using the standard integration forms to access services, select methods, map available data, and merge results into the case or work object.

It is critical for enterprises to have BPM capabilities that will grow with the business and run on the platforms they need. Pega’s SmartBPM Suite is able to run common rules across platforms driven by a dynamic RuleBase repository.

There is a common library of shared and ready-to-reuse business software components that make the most of the abovementioned situational layer cake to let businesses quickly leverage shared assets. A virtual enterprise rule base (VERB) takes all of those application-specific assets (i.e., the integration components, UI designs, process flows, business rules, organization structure, and, indeed, complete applications) and shares them in a federated process registry and repository.

Consider an all-too-common customer service environment with multiple platforms starting, e.g., with an IBM WebSphere-based call center and an interactive voice response (IVR) unit based on Microsoft .NET Framework. Then we could imagine individual branches running on Sun Solaris or Linux-based servers, while the bank might also need an Oracle WebLogic application server farm, and the need to run in the batch processing environments that handle mass processing of transactions.

SmartBPM has a notable ability to run concurrently inside all of these environments to provide the needed flexibility.  Indeed, what sense does it make to create business rules and processes if they cannot run across all those diverse IT environments?

This hardware- and software-related flexibility is the key to running simultaneously across multiple operating systems (OSs), including Microsoft Windows, Linux, Sun Solaris, IBM System z mainframes, and IBM AIX. Pega also uses leading application servers including IBM WebSphere, Oracle WebLogic, and Apache Tomcat. Unified processes and business rules reside in the abovementioned common repository (database), which may run on Oracle, Microsoft SQL Server, and IBM DB2 relational databases.

The architecture also supports parallel computing so that multiple nodes are available to scale up and support distributed user bases and provide resiliency. SmartBPM’s impressive combination of a distributed and heterogeneous server architecture and a centralized rule database provides the required scalability and reliability for mission-critical BPM applications.

Companies can start small with pilot projects and departmental solutions and grow towards extensive enterprise backbones. Last but not least, the offering also has some system management and autonomic (self-healing) computing capabilities.

The final part of this blog series will complete the series with thoughts on what the future might hold for Pega, including inevitable challenges. In the meantime, your comments, thoughts, suggestions, or individual experiences with both Pega and other BPM tools are more than welcome.
 
comments powered by Disqus