Business Process Management Adoption: Get it right the first time

Business Process Management Adoption:

Get it right the first time

Business Process Management (BPM) brings stability and productivity to client reporting organizations, but without the right business architecture integration challenges can hinder usability and adoption.

Our business partners face a pervasive tug-of-war within the client reporting arena as they struggle to find new ways to improve client satisfaction. Our customers, investment managers and client advisors, wrestle with data quality and timeliness issues. At the same time, technology and operations management partners seek to improve process productivity and effectiveness with leaner budgets leaving major platform investments hung up in planning stages.

The convergence of these challenges is leading to a broader adoption of

K

I

volume 2 no. 2 March 12, 2012

Contents

BPM andthe Value Chain ...2

OrganizatiOn: SilOSOr BuSineSS COMPetenCieS? ... 2 PrOOfOf COnCePt (POC) .... 3 POC aPPrOaCh ... 4 SOlutiOn trade-OffS ... 4 COnCluSiOn ... 5

BPM

V

C

BPM technology provides consistency and transparency to complex manual (human) and system steps required to complete a process value chain. In the financial services industry, automated BPM technology is typically used to stabilize operational processes like account opening and client onboarding. It enables advisors and administrators to monitor the progress of activities executed by back and middle office personnel and support functions such as compliance, vendors and business approvers. This view or “portal” into the existing business processes stabilizes disparate procedures, provides transparency and enables optimization. As a result, sophisticated organizations leverage this technology to drive new efficiencies by applying engineering quality methodologies like Six Sigma to financial business processes.

As operations and technology managers gained experience with the tool sets, the business architecture question naturally arose, to what extent should this BPM philosophy be applied across the organization?

O

: S

B

C

?

When evaluating the touch-points for client reporting, analysts find that many parts of the organization contribute to the client reporting value chain. The basic case for which groups contribute sequentially to the production of reports can be visualized according to traditional roles:

However, the problem gets more complicated when parallel, upstream, or downstream business areas get involved in the client reporting process. Complexity encroaches into the systems and processes:

How are data dependencies managed and escalated? Who owns data quality?

How do we resolve issues across business units? Where are the redundant processes?

How does system latency impact client satisfaction? Can single data architecture support all needs, given conflicting requirements for timeliness and data quality?

Many organizations try to address this complexity through a technology focused lens. One of our clients, a senior manager for a global insurance firm responsible for client reporting, tackled the problem in a different way. They initiated a program to first analyze all business competencies across the organization. Our client then asked the following three key questions of their senior management:

What are the capabilities that define our business? What are the business services those capabilities require?

What people, process, or technology is required to support the business services?

Figure 1: Basic Client Reporting Value Chain

Reference

By restructuring the questions, our client helped the firm focus on the business goals and objectives first, and left questions concerning technology last. Instead of asking which technology initiatives can solve our data quality issues we ask, “What business capabilities are being defined, and who is accountable to complete them?” This has major ramifications for a firm looking to adopt BPM technology on a wider scale. In other words, it is not about the “data hub” capability ownership and accountability.

The next step was to philosophically redefine the organization across explicit or implied business capabilities and begin to map the supporting business services for each capability. This map into the

organization was used to constitute a key hotspot for the business, namely client reporting, conceptually changing the organization from a series of silos to interconnected business competencies.

P

C

(POC)

Our clients wanted to avoid the common implementation pitfalls. The industry is filled with stories of

well-intentioned quality and process improvement efforts that start strong and achieve a degree of success, but eventually fade away into oblivion. Impatient business users of client reporting data (correctly) demand concrete proof that a new approach yields tangible benefits and are not another passing fad. To demonstrate the feasibility of applying the BPM philosophy to an existing organization, our client stakeholders agreed with senior management to prove the concept first through solving a real business problem.

Their challenge was getting the middle office to release investment management data on a daily basis for use in daily asset allocation monitoring, when previously only monthly data was available. The BPM strategy team accepted the challenge and proposed to achieve the following commitments:

Showcase the BPM tool orchestrating the new value chain

Demonstrate a new business service (i.e. to produce interim data on a daily basis for users who need increased frequency, add new asset classes, etc.) Identify role conflicts or process gaps that would impede business-centric BPM reengineering Identify technology gaps

Create a peer-reviewed report card of progress vs. goals and get external validation of the approach

Figure 2: The Logical Reorganization of Silos based on Business Capabilities (Blandizzi, S.; Palangio, M.A.)

t

POC a

The client engaged Knowledgent to help define the applied strategy and provide execution support. The approach was to execute both top-down and bottom-up analysis to determine what change management plan was required (Recker). The top-down approach defined the new business processes in the BPM tool and showed both primary workflows and alternate flows needed for exception handling procedures. The bottom-up project approach defined the business requirements, use cases and data frequency requirements needed to support the new asset classes that are outside the current enterprise data hub. This effort required analysis at the data element, or field, level and data sampling to define and validate business rule consistency. The basic iteration that was used for completing the analysis is shown in Figure 3.

The results of the POC analysis uncovered a set of hitherto unknown design considerations across

S

t

-O

Several interesting questions arose during the POC which drove healthy project debate and engaged senior leadership to clarify and propose solution options. The first question, what degree of control should the BPM tool assume? The options range from coarse-grained dispatch and tracking, to fine-coarse-grained SOA service calls or manual process workflow (Bergland, Maquil and Nguyen 17,41-49). To support a model that would ensure maximized flexibility for their BPM approach, our client would require the finest-grained service possible. However, since none of these services existed, the team agreed to adopt a reasonable compromise of coarse-grained control in order to maximize time-to-market. The “swivel chair” solution signified that acceptable for the BPM controller to expect a user to “swivel” into another application to process exceptions, and “swivel back in the chair” to relinquish control back to the BPM tool.

Figure 3: POC Analysis Approach

Similarly, the primary business process questions that arose are related to how exceptions should be processed. Traditionally, technology tools embed user interfaces and workflows into their applications and expect operators to make changes in one system. However, in an enterprise changes may need to be made in a variety of systems, some of which could be either upstream or parallel to the current process. Adopting a BPM centric approach required defining an exception handling and business/quality rules framework that spanned business processes, systems and job roles. The framework needed to address:

What business rules should be utilized?

What roles are responsible for guarantying data quality?

Where these rules should be applied and maintained? What quality steps can be automated?

Finally, the POC surfaced a set of technology questions, besides typical integration questions concerning SOA services and return calls. Specifically, how much data should be passed among cooperating systems? What kinds of transport layers would provide the necessary business performance and required resiliency needs (e.g. synchronous web calls or asynchronous message bus architecture)?

Another technology debate centered on the degree that “human + computer” BPM tool should replace the existing computer-only job schedulers. BPM tools are designed to incorporate human steps into workflows by adding people, process and technology to the equation. For the sake of simplicity, the joint Knowledgent/Client

There is a case to be made for integration challenges that were not experienced during this POC but can be expected in a full production environment of BPM, SOA, and ESB technologies. Challenges with service version and software configuration management have been cited in this white paper literature for your convenience (Hohwiller, Joerg; Schlegel, Diethelm).

C

: t

BPM

C

r

BPM technology has been commercially available for over a decade, but we are only beginning to see client reporting data hub vendors capitalizing on the advantages of integrating their products with third party BPM tools. Projects should anticipate integration dependencies between client reporting data hub vendors and BPM tool vendors.

With the strategy of providing verifiable transparency into the inner working of client reporting teams is, and will continue to be, a compelling message to business partners and operations teams. We predict a broader adoption of BPM technology solution approach across client reporting in the near future.

Knowledgent Insightsoffers business and strategic insights on the latest trends affecting information efficiency and management that drives strategic growth decisions. For more information on the subject matter covered in this issue, contact info@knowledgent.com

About Knowledgent

Knowledgent (www.knowledgent.com) is a leading industry consulting and information management firm. It combines deep industry expertise with advanced information management capabilities to maximize the value of information to empower clients to make informed strategic decisions. Knowledgent leverages large-scale analytics, unstructured data mining, semantic integration and master information management to help clients optimize business operations. Founded in 2009, Knowledgent has offices in New York City, New York and Warren, New Jersey.

© 2012 Knowledgent Group Inc. All rights reserved. Bergland, John, et al.

BPM Solution, Implementation Guide. Cambridge,

MA: IBM Redbook series, 2009. PDF. Blandizzi, S.; Palangio, M.A.

GFIS Strategy Presentation. Toronto, 27 Sep 2011.

Hohwiller, Joerg; Schlegel, Diethelm.

Software Configuration Management in the Context of BPM and SOA.

Offenbach, Germany, 22 02 2012. Website. Recker, Jan.

“Process Modeling in the 21st Century.”