BPM Voices: Synchronicity: An agile approach to business process management

Perhaps the most difficult aspect of business process management is the ability to quickly develop business processes. With traditional SOA-based BPM solutions, the skills and development needed to implement even simple processes limits the ability to respond quickly to changes. Pair this with a lack of collaboration and shared understanding between business and IT stakeholders and you can see why many BPM projects get mired in prolonged development cycles. However, recent changes in this area, including emerging solutions such as IBM® Business Process Manager, support a more agile approach to BPM process discovery and development, reducing the time to market and ensuring a tighter alignment between business and IT. Using tools and techniques such as Blueworks Live, process discovery workshops, and iterative BPM development, IT and business can work together to design solutions. This approach helps to ensure that requirements are addressed during design and development instead of the traditional approach where business hands off requirements to IT with the hope that the final solution meets the requirements. In this column, we'll talk about these BPM challenges and discuss how to apply an agile BPM approach to address them. This content is part of the IBM Business Process Management Journal.

Scott Simmons, Executive IT Architect, IBM  

Scott SimmonsScott Simmons is the Banking Solutions Architect for IBM’s North American Business Process Management Solution Architecture Team. Scott specializes in design, development and implementation of BPM solution architectures for banking and financial markets customers and key ISVs. Previously, Scott was the Lead Banking Solutions Architect for IBM’s WW Banking Center of Excellence for 3 years. Scott also held the position of Principal Architect for IBM’s Worldwide SOA Technical Architecture team for 2 years. In both of these positions, Scott has represented a key leadership role for the development of the SOA-based solutions in the Banking and Financial Services Industries. Scott is an IBM Senior Certified IT Architect and Distinguished IT Architect with the Open Group. Scott is a co-author/contributor on multiple IBM Redbooks and has been published in numerous periodicals including the IBM BPM Journal, WebSphere Developer Technical Journal, Web Services Journal, XML Journal and WebSphere Journal.


developerWorks Contributing author
        level

Michael Steele (mikesteele@us.ibm.com), Solution Architect , IBM

Michael Steele photoMichael Steele is an IBM Solution Architect with IBM’s North American Business Process Management team. As a solution architect, Michael leverages his extensive multi-domain and industry field experience to lead, support, and drive solutions around business process and business rule driven industry solutions. Michael has developed solutions for Property Casualty Insurance, Life Insurance, Healthcare Payers, State and Local Government, and Heavy Manufacturing. Michael’s experience, background, and education are based on working with business rules management systems, business process management, and complex integration requirements. Prior to joining IBM, Michael was with Webify, Vitria, Blaze, Platinum Technology, Inc and LTV Steel. Michael is a co-author of a Redbook on the IBM WebSphere Business Services Fabric.



15 February 2012

Introduction

Synchronicity

A connecting principle
Linked to the invisible
Almost imperceptible
Something inexpressible

The Police, 1983

The song "Synchronicity" (see sidebar for lyrics) describes an invisible force that guides and connects actions together. In a similar fashion, the ability for business and IT to connect seamlessly as part of an agile approach to BPM implementation transcends the traditional chasm between IT and business requirements. By focusing on BPM requirements and BPM design as a collaborative rather than confrontational activity, companies can optimize their BPM success. But this collaboration is not easily realized – this approach challenges IT and business to deliver value through an interlocked approach – sharing common goals and working together to develop solutions. An article in developerWorks last year (Successful BPM takes a true team-oriented approach ) discussed this team-oriented approach to BPM. This article is intended to supplement that earlier article by introducing three key foundational elements for a collaborative agile BPM development approach: Blueworks Live, process discovery workshops, and playbacks.


Key challenges in BPM development:

Mike and I are BPM Solution Architects – in this capacity we work with clients around North America on the development and deployment of Business Process solutions. In our work as solution architects assisting clients in BPM design and development, we have seen three key challenges in BPM development:

  • Lack of business and IT collaboration in solution design.
  • Limited or discontinuous requirement definition and process modeling.
  • Long development cycles tied to traditional application approaches.

Regarding the first challenge, to be blunt, business and IT do not "share" well. Business wants to leave technology to IT and, conversely, IT often accepts business requirements without understanding the specific business objectives. As a result, solutions delivered with this approach usually miss the mark and result in suboptimal success with BPM and a lack of trust between business and IT.

As an example, one current client was endeavoring to redesign a database-driven business process solution. IT believed the key objective was to design a more user-friendly user interface for the business users, but the business users simply wanted to reduce the current 6-month delay between new solution requirements and change implementation. This appears to be simply an issue of miscommunication, but it is one that is challenging the relationship between business users and IT, and causes other downstream problems. If this client's business and IT stakeholders were to collaborate together on process and rules discovery, they would realize outcomes that would be beneficial for both groups.

This gap in collaboration contributes to the second challenge: limited or incomplete requirement definition and process modeling. We find that too often there is "business-speak" and "technical-speak" and the two languages do not meet. The business often does not know what it actually needs, so it's no surprise when the developed solutions fail to deliver. Business stakeholders are often constrained by their view of the current solution (with associated challenges), and it's difficult to define the envisioned solution. One fundamental reason for this problem is that business users do not have a view of what can be accomplished and are impacted by minimal process modeling skills. If business and IT were to jointly define the scope and objectives of the desired solution, organizations would observe much higher satisfaction levels with the final solution.

The third and final challenge is applying traditional development approaches to BPM implementation. The rocket science that is embedded in many BPM tools makes it difficult for the common business user to understand development aspects. Additionally, far too often IT goes into its silo to build the new mousetrap and then emerges weeks later with a solution that does not correspond to user requirements.

What is needed is an iterative approach to allow business and IT to work together on design in terms of process flow and solution definition aspects. Through an agile BPM approach, organizations can more quickly realize the benefits of a collaborative BPM approach and implement quality solutions more quickly.

A good friend, Greg Pope, once remarked that "BPM is a three-legged stool - product, method and a BPM Center of Excellence. I you get this right, you'll be successful." A good tool can make a hard job simple but finding the right tools is not always easy and using them properly is a skill. However, realizing these tooling goals is a secondary issue – it's more important that you have a method that supports collaborative development. If you adapt the development approach with an agile technique, you'll realize multiple benefits, including cost savings, risk reduction, and greater user satisfaction. If you do, the challenges described above can be minimized. We'll leave the concept of establishing a Center of Excellence (CoE) for a later discussion, but we should note that a BPM CoE can provide an infrastructure to scale BPM from a project focus to an enterprise competency.


Agile BPM: What's it all about?

First, we need to define agile. Wikipedia defines agile as follows:

Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle."

An agile development methodology is an approach to both software development project management and solution implementation. The challenges of missed deadlines and suboptimal solutions that result from waterfall methodologies (that is, traditional sequential development) are a primary reason for using an agile approach. Agile development practices allow IT organizations to respond to the unpredictability of building software. This response is enabled through the introduction of an incremental, iterative methodology with IT developers and business users collaborating on solution definition and implementation. The benefits of an agile development approach are:

  • Deeper understanding of a problem and the associated requirements.
  • Collaborative design leading to faster time-to-market.
  • Increased ability of the team to quickly prototype solution design.
  • Shared vision and commitment to the solution by business and IT.
  • Incremental design validation, common understanding and commitment, which allows solution changes without radical changes in project trajectory.
  • Optimizes success of project through team ownership.

But the devil is in the details. An agile approach often requires a high level of cultural readjustment because it effectively redesigns the software development process as it shifts development from an IT-centric waterfall approach to one that is founded on an iterative approach to solution design and implementation. In many organizations, implementing an agile approach runs counter to the traditional roles of both business and IT. As a result, it is important to have executive sponsorship of these types of initiatives to establish a mandate for change.

The key focus of this article is agile BPM. What do we mean by agile BPM? Is it just another way to look at BPM? No, an agile BPM approach enforces a framework by building on the basic foundation of agile software development in two key BPM-specific areas:

  1. Process discovery
  2. Process design and implementation

In the area of process discovery you can employ an agile approach through the use of collaborative tools for process discovery, such as IBM Blueworks Live, with the introduction of Discovery Workshops. The Discovery Workshop approach is based on JAD (Joint Application Design) techniques. These two tools provide the initial formative steps in Agile BPM. During process design and implementation, we expand on the JAD concept with the introduction of playbacks to support interactive solution development with clients via prescribed phases that correspond to a sprint approach in agile programming.

Before we describe these tools and capabilities, it's important to note that an agile approach is critical to realizing success with BPM. BPM often tries to reconcile perceived requirements with observed business practices. Without a common grounding in requirements and vocabulary between business and IT, solution realization is constrained. By focusing on BPM design as a collaborative task between business and IT, we bridge the gap between "what is needed" (business) and "what is possible" (IT). Application of the techniques in this article will facilitate the BPM discovery and design process and lead to increased success with BPM initiatives. However, like any technique, it takes practice and refinement to master these techniques.

Agile BPM is evolutionary; it takes time for business and IT to acclimate to the new process and modify traditional (and sometimes dysfunctional) behaviors. Though we'll explain the methods in a bit more depth later in the article, it's important to state that unlike an approach based on traditional, periodic design reviews with the users, discovery workshops happen often (and are more than just an excuse for sandiscovery workshopiches or pizza!). In solution development, we find that the playbacks are performed in a consistent and predictive manner, and success with playbacks requires a shift in how development is normally accomplished.

So why should you care? Well, it's pretty simple. It's a matter of time, speed and costs. Regardless of any rhetoric to the contrary, IT and business (in general) do not share the same lenses and have different perspectives and goals. Through a collaborative discovery and design process, each side can view the method through each other's lens. This promotes learning, sharing and understanding by both business and IT, but more importantly it often means the difference between marginal success (at best) and an optimal environment for BPM development.

Let's look in more depth at the components of an agile BPM approach, focusing on process discovery and development and implementation.


Agile process discovery

Process discovery is an activity that seeks to define an organization's current business processes and variations. The process includes both business and technical aspects and provides the foundation for process implementation. In the past, process discovery was done via a whiteboard (with the standard "DO NOT ERASE!" written at the conclusion of an 8-hour coffee drinking group session), PowerPoint or Visio (which suffer from a lack of consistency, rigor and reuse), or sticky notes. One client actually had an entire wall that contained hundreds (possibly thousands) of sticky notes with yarn connecting boxes to represent high-level process flows and task hierarchies.

In our BPM engagements with clients, we see process discovery consisting of three activities:

  1. Documenting the key processes in terms of milestones and activities, including key actors, systems, process owners, cycle time, cost, inputs, outputs, risks and challenges, as well as identifying the supporting documentation.
  2. Defining high-level process flows (such as Level 0 or Level 1) with both business and IT for the current processes as well as the "to-be" processes. One challenge here is thinking outside of the box, having business users consider what could be versus being constrained by the current solution (or lack of a solution).
  3. A collaborative process brainstorming session with business and IT to define overall requirements and jointly determine both feasibility and alternatives or approaches.

The key is synchronicity! The requirement for business and IT to collaborate on process discovery is critical to BPM success. Business users usually understand what they do and how they do it, but this information is often siloed and undocumented, found only within people's heads. Moreover, business users only know their portion of the process, but complex processes span organizational teams. Additionally, even with a business analyst and the ability to capture this knowledge, business is challenged to define requirements so that IT can easily understand and reconcile them. In one client situation, a business user articulated the process as if it were written in a book, but when an engineer who performed the process was interviewed, it was clear there was a disconnect on the basic process flow. Without a joint understanding between all key users, as well as business and IT, achieving even suboptimal BPM solutions is nearly impossible.

Blueworks Live

IBM Blueworks Live provides a solution for the first two activities in process discovery: definition of key milestones and tasks and providing an approach to graphical design of the key process flows. Blueworks Live is a powerful browser-based cloud-enabled whiteboard, but success in process discovery requires more than a tool, it mandates an active commitment by both business and IT to be successful. It also requires a transparent environment with open communication that supports brainstorming. Finally, it requires a shared and trusted environment in which stakeholders can review the work of others and enhance or comment on the artifacts as they are defined.

Let's look at the tooling aspect. In Figure 1, you can see the interface of Blueworks Live for milestone definition. Besides allowing the creation of key milestones and associated tasks in chronological order, Blueworks Live also supports the documentation of key process attributes, such as process owner, external systems, cycle time, costs, and risks, to help develop a definition and design baseline for As-Is and To-Be processes.

Figure 1. Blueworks Live discovery map
Blueworks Live discovery map

(See a larger version of Figure 1.)

Figure 1 shows a discovery map. Each column represents a topmost milestone with the boxes underneath representing the individual activities within that milestone.

The other key capability in Blueworks Live is the process diagram support. Blueworks Live directly converts discovery maps into process diagrams. The conversion results in each column representing the defined milestones and the generation of key generic roles into swimlanes. Blueworks Live creates the associated start and end markers and assigns the tasks or activities from the discovery map to activities in the swim lanes of the process diagram. To allow further refinement of the process, Blueworks Live provides a palette to allow the team to create decision points, inclusive or exclusive gateways, event notification functions, and subprocesses. The underlying approach for the process diagramming is BPMN 2.0 (Business Process Modeling and Notation). Blueworks Live processes can be directly subscribed to using IBM's Process Designer for solution implementation activities. One key leading practice when using Blueworks Live is to finalize key milestones or activities in the discovery map before converting them to the process diagram. Although you can embellish the process diagram after the conversion, it's is easier and more straightforward to have a complete or nearly complete activity design prior to beginning high-level process design. Figure 2 depicts a process diagram, showing the process diagramming palette.

Figure 2. Blueworks Live process diagram
Blueworks Live process diagram

(See a larger version of Figure 2.)

Another leading practice associated with the initial Blueworks Live process design is ensuring consistent task decomposition during design and review work. It's optimal that tasks at a given level (for example, Level 0/1/2) are similar in granularity, for example, size, duration, scope, to support a consistent logical flow.

Blueworks Live becomes the key tool for enforcing a collaborative design approach to rough-cut process design, discovery and definition. We find that organizations using Blueworks Live with this collaborative teaming approach achieve higher levels of BPM expertise in the organization as well as greater effectiveness for BPM initiatives in terms of both user satisfaction and time-to-market. There is a huge value in having the stakeholders directly participate and "own" the actual process. At the same time, patience is needed during discovery to reconcile the perspectives of different constituencies. It can be challenging to develop processes that are agreeable to all stakeholders.

Often when organizations introduce Blueworks Live, IT development is somewhat wary at first at what may seem like a loss of power and control. They find out quickly though that the benefits of participation by the business not only outweigh the organizational concerns, but that the iterative process discovery can drive the commitment of the business stakeholders in the design and implementation. At one financial client, the system integrator used Blueworks Live to build the 12 key process diagrams with their client and used the process designs to support their subsequent proposal for BPM development. The proposal was accepted promptly by business as it directly mapped the desired solution in the language of the business (no surprise since it was created as a joint collaborative effort between the integrator and the line of business).

As a final step in Blueworks Live-based process discovery, stakeholders should evaluate the key tasks to determine whether further decomposition is warranted or whether further optimizations are suggested. As an example, if a task includes multiple steps and multiple people or roles responsible for each step, it's likely that each step represents a distinct task. The evaluation process may result in combining activities, designing parallel steps to reduce time and cost, re-evaluation of key roles, and elimination of non-value add tasks.

Note that Blueworks Live also provides simple process automation capabilities that are mediated over email. This capability is outside the scope of our discussion, but you should note that this functionality provides Blueworks Live users the ability to automate simple manual tasks. This process execution function also allows the business users to visualize completed tasks, tasks that are in-process and tasks that have missed specific deadlines. Blueworks Live also provides community functions for collaboration including a social bulletin board for BPM conversations and a library of process templates covering many different domains to accelerate BPM discovery. Finally, it is important to note that Blueworks Live processes can be used just for documentation – taking them forward into development is appropriate for some, but not all processes.

Discovery workshops

Over the years, the concept of getting business and IT into a room to do solution requirements and design has been a traditional element of the software development process. Unfortunately the stakeholders normally sit on opposite sides of the table and the meeting accomplishes little except producing more documentation. The reason for the lack of success is simple – there is not a shared commitment to the outcome for either the workshop or the solution itself. In our BPM engagements, we introduce the concept of a discovery workshop. Initially we used these workshops to support primarily decision management areas (such as business rules) but they have grown to include BPM and operational monitoring and analytics. The discovery workshop is a customizable one- to two-day day session designed to define the common problem and the solution design. The key outputs of the process include definition of the business case, elaboration of the As-Is and To-Be states, identification of key success factors, such as KPIs, timelines or roadmaps, articulation of anticipated solution benefits, and a documented solution overview with recommended approach, architecture design, a design and development approach and key next steps.

We often find that organizations will use the Blueworks Live tool as one aspect of the discovery workshop, but the approach is open. A discovery workshop can be held prior to using Blueworks Live, as a parallel activity with Blueworks Live being used in the workshop, or as a subsequent step after an initial process discovery session by the business stakeholders using Blueworks Live. We have seen clients use all three patterns - it's a matter of organizational preference as well as the comfort and ability of the business team to do initial process discovery in Blueworks Live as an independent activity.

From a tooling perspective, many tools can be employed to deliver a discovery workshop. Often the use of Blueworks Live and a whiteboard to support design discussions are the key ways to capture information but, as with Blueworks Live, the power of the approach is in the method and not in the tools. Two components are critical for the delivery of a successful discovery workshop:

  • An open atmosphere of trust with frank, honest and direct discussion on requirements and the solution approach (without retribution).
  • A facilitator who acts as an intermediary and a coach, ensuring the team reaches conclusions to support either a go-forward or a stop-work decision.

In addition to the definition of the as-is and to-be business processes, we find that development of key architecture work products can be advantageous in the workshop. Key artifacts might include system context diagrams, use cases, architecture overview diagrams, and documenting key architectural decisions. At the same time, you don't want the creation of work products or the use of a tool like Blueworks Live to obfuscate the task at hand. The most important objective is clarification of the business case and putting this business case into actionable steps. Often this includes an assessment of the key market and technology trends to define relevant opportunities and threats. The key is to focus on the business problem and not on the technology problems.

The definition of scope and constraints, key use cases, and an overall solution approach are employed to determine a go or no-go decision and roadmap. Additionally, the project team normally develops a high-level estimate of the timeline and necessary resources to ensure that the project can be done within budget constraints. At the conclusion of the process, the solution definition and design will either be elaborated or the project will be de-prioritized or cancelled altogether. The key is that this decision is reached through consensus of the key stakeholders - business and IT.

In terms of participants in the discovery workshop, key roles that should be involved include the executive business sponsors, solution architect, enterprise architect and business analysts. It's important to have enough people to drive consensus and provide well-framed recommendations; however, it's also critical that the participant list not grow too long that it seriously compromises the management of an agenda by promoting a "who can scream the loudest" discussion. In addition, it's best to have people attend the entire workshop versus dropping in sporadically. For this reason, we often host clients in an IBM facility to limit distractions and outside influences. Finally, it's essential that someone is responsible for maintaining a log of the discussions during the workshop. This transcribed content is then integrated into the final deliverables.

During the workshop, a number of key questions must be addressed:

  1. Is a business process or decision management approach right for the issues at hand?
  2. What are the main risks or challenges associated with the issues at hand and what are possible mitigations?
  3. What are possible solution scenarios and alternative approaches?
  4. What are the key next steps be to support the project?

What is amazing during a discovery workshop is that the facilitator will often let the business and IT stakeholders "go at it." There are frequently stark differences in definition and objectives. By letting both sides actively engage in the discussions, we find that conclusions can be reached with higher consensus. At a recent workshop, the business and IT leads actually went into another room for two hours to work out their differences. Fortunately, no furniture was damaged and no 911 calls were necessary! Should these types of off-line discussions happen? Optimally no, but we find that sometimes organizations need the latitude to work things out in a manner consistent with their corporate culture.

A key goal of the workshop is creation of a set of artifacts to guide ongoing development. Normally this includes the following work products:

  • Project stakeholders – names and roles of business and IT project team members.
  • Actors or roles – includes users, systems of record, data stores, or applications.
  • Business case overview - often expressed as a system context diagram.
  • Current as-is situation - often expressed as a logical solution diagram.
  • Desired to-be situation - often expressed as a logical solution diagram.
  • As-is and to-be process flows - developed via Blueworks Live or alternative approaches.
  • Success factors or KPIs - the metrics as well as the means to measure.
  • Roadmap or timeline - defines incremental solution milestones.

Discovery workshops are normally 2-3 days in length, depending on the amount of education needed on areas such as BPM, process discovery, and decision management. Normally, we use a basic flow to conduct these workshops that consists of the following steps:

  1. Introduction: Agenda and introduction.
  2. Business case: The business stakeholder provides a presentation or leads a discussion to review this area, which includes:
    • Discussion on organizational stakeholders (and process or rule owners).
    • Focus on business architecture aspects.
    • Skills assessment and gap identification related to BPM and decision management.
    • Discuss and define project scope and constraints.
  3. Define as-is (current) and to-be (desired/envisioned) environment.
  4. Define key functional use cases and desired outcome, results, success factors.
  5. Define and document the overall business solution roadmap, approach, timeline.

In addition, depending on time, we will often elaborate on BPM aspects, such as process characteristics, process owners, potential patterns, process measures and detailed KPIs, definition of the current high-level process map and associated business entities and an overall architectural and development approach. If the discovery workshop is mainly focused on decision management (business rules), we will often do further definition on the specific business rules and events, their relationship to specific business process, types of rules, rule sources, rule owners, and a brief review of the rules development approach for the project.

The final deliverables are very organization-specific. Normally, when the IBM team does a discovery workshop, we provide a hardcopy report and an executive presentation within 1-2 weeks. Both the report and the presentation restate the issues and challenges ("findings"), describe the current and envisioned solution ("observations and requirements"), and present the proposed solution ("alternatives" and "recommendations) including a high-level roadmap, architectural approach, and next steps. The roadmap is a key component because it shows both key tasks and the development timeframe, as shown in Figure 3, and calls out interim build milestones as appropriate.

Figure 3. Sample roadmap
Sample roadmap

The report needs to be reviewed and approved by all key stakeholders and when discrepancies arise; the deliverable should discuss these deltas and potential resolutions. Once complete and validated, the team can move towards development and implementation activities.


Agile process development and implementation

The final part of our discussion of agile BPM is the development and implementation phase. We find that a key component to BPM success is iterative development via playbacks. Playbacks are interactive sessions whose purpose is real-time development and review of solution functionality for all key stakeholders. A playback is not simply the execution of a portion of the solution or an ad hoc demo, it's an opportunity to involve the participants and owners of the process in a concrete and participatory way. Often, we see business users actually running the playback sessions, with coaching from the technical team where needed.

But let's step back for a moment. First, we must understand that both BPM and decision management solutions are composite applications consisting of multiple components including rules, KPIs and metrics, events, database sources and targets, application sources and targets, service invocation, user interfaces, as well as data, process and rule flow. This is often confusing for some of the technical team, but it really confounds most business users! After about 5 minutes, these users are normally focusing on their mobile devices, checking email on their laptops, or even sleeping. For this reason, the playback process needs to be active. It should provide validation that the process design is headed in the correct direction and this, in turn, fosters business ownership and solution buy-in and sponsorship. This is the pièce de résistance for agile BPM – this buy-in enables business to become an active part of the development process and to assume ownership of the solution.

In our view, each project should have at least four milestone playbacks with the following audiences:

  • All business participants (at least one representative of each stakeholder group).
  • All business stakeholders in the process.
  • Process owners (normally from the line of business).
  • Process and technical architects and developers.
  • Engagement managers (lead technical team lead and project manager).
  • Infrastructure architects to support design of the operational solution.

Each individual playback needs to identify goals and expectations (similar to defining a sprint in agile software development) and should additionally define the playback scope as it relates to the overall solution. This definition of the playback activity provides context for the specific aspects of the solution, allowing the participants to focus on functional, business value portions of the process. During playbacks, we find that skilled playback facilitators put items into the "parking lot" as often the technical team goes into deeper technical directions than is warranted or business users focus on non-essential aspects (such as, call this button Open Application instead of Next Step). Finally, as part of overall design, it's important to predetermine the end-to-end playback strategy for each BPM project to ensure that it fits together in a consistent and timely way. This strategy will normally define the schedule of playbacks that relate to specific milestones with an evaluation of the required elements of the solution (as determined in the discovery workshop), and some level of sign-off or approval at each milestone playback.

In our work, we find the following general approach to playback strategy provides the desired results:

  • Playback 0 - Focuses on high-level business process understanding. Usually this is the result of process discovery work covered in the agile process discovery phase described earlier. The key is the delivery of an executable process definition (BPD) showing key tasks in the process (but not showing the implementation). BPD swimlanes normally show the key roles in the process. Finally the process will expose a basic information model and optimally the initial rough-cut report and dashboards.
  • Playback 1 - Focuses on user interface design and implementation. This playback may be done multiple times to ensure a consistent approach to the user interfaces. The intent is not to finalize the user interfaces, but to ensure that they satisfy the key requirements. The IBM Business Process Manager Process Designer employs a "WYSIWYE" (What You See Is What You Execute) approach that enables the workshops to be highly collaborative sessions regarding process flow, user interfaces and overall solution context. Normally, this playback also includes some elaboration of the process data model to meet UI and decision management requirements.
  • Playback 2 - Focuses on integration and external connectivity. Although we may not implement all interfaces, this playback concentrates on the handshakes needed between external data, service and application sources, as well as exception handling aspects and service level agreements for the external touch points. Like playback 1, this playback may be iterated multiple times based on completion of the high-level objectives.
  • Playback 3 - Focuses on the consolidation of earlier playbacks to render the final, tuned end-to-end solution. Normally, this playback comprises all necessary implementation details, including process flow, interfaces and integrations, and should result in a solution that is ready for initial user acceptance testing (UAT).

Figure 4 shows the relationship of the playbacks to roles and time. Timings are approximate and depend on process complexity and the organizational BPM maturity.

Figure 4. Playback timeline and roles
Playback timeline and roles

(See a larger version of Figure 4.)


Example 1: Institutional onboarding

Finally, let's take a look at a couple of uses cases where agile BPM has been successfully applied. We've been working with multiple clients in the area of institutional on-boarding. One client recently underbid an onboarding project and ended up losing millions of dollars as a result, so this became a great candidate for process discovery.

This subject domain involves a broad range of functions often found in asset management services and corporate banking, but there are many common components in the solution definition. We've worked with a number of clients on developing a set of acceleration artifacts. For example, in Figure 5, you see the discovery map from Blueworks Live that we used to begin to define an approach.

Figure 5. Onboarding example discovery map
Onboarding example discovery map

(See a larger version of Figure 5.)

Working with these clients, we created a template that serves as a discussion document for other clients. Working with similar solution requirements, we can create a copy of the above discovery diagram and then embellish the Blueworks Live outputs to support a specific client's requirements. We can then generate the process diagram and extend it to support new requirements as shown in Figure 6.

Figure 6. Onboarding example process diagram
Onboarding example process diagram

Using this approach, we can accelerate the process discovery phase for clients. These artifacts become the key input for the process discovery workshop, as well as initial solution designs using playbacks to support the development of prototypes. With one client, we also used this method to lead to a business value assessment that provided an cost/benefit analysis for the envisioned project.


Example 2: Media distribution

Our second use case focuses largely on the discovery workshop. This client is a distribution house for a large production studio. Distribution activities are time critical, highly customized and vary from simple DVD preparation to full global distribution. Digital media has changed the techniques and activities associated with typical production work, so much so that delays and errors have become commonplace in a process that was for many years consistent and highly predictable.

A discovery workshop quickly identified the steps and activities that make up the process. Roles, systems and timelines were better understood, as were the driving events that created the distribution order, such as sales activities. Documents were presented that described the process, roles and activities. The discovery workshop team noted quickly the lack of measurability and visibility into the process.

A key point in the discovery workshop was the execution of a process review from actual distribution floor engineers and technicians. As an outcome, the discovery workshop became more than discovery, it became an awakening to the core problems. The process and activities described by the engineers and technicians were not aligned with the process as described by the business owners. In fact they were contradictory in some respects, so much so that at one point the discussions became argumentative. We discovered that the process thought to be well understood was, in fact, not clear to either party.

Leveraging Blueworks Live, the workshop sessions enabled the alignment of the processes. Multiple collaborative sessions were held to quickly achieve continuity, consistency and reality. Using an agile approach, a realistic and meaningful process emerged that was agreed to by both business and operations. Additionally, the discovery workshop and Blueworks Live helped address the real issues in overall process improvement: reducing errors, meeting demanding timelines, and high predictability.

Discovery workshops are critical tools that drove agile BPM for this use case. The business stakeholders understood what needed to happen, while operations understood clearly what was required to deliver results. By bringing both of these perspectives to the table, and merging them into one clear process through an iterative and collaborative process, the client was able to realize a BPM breakthrough.


Key principles for agile BPM

Let's conclude with a list of key principles for an agile BPM approach:

  • Use process discovery techniques to enable end users and business analysts to define their desired functionality and priority for inclusion into the solution.
  • In process discovery, try to identify common components as you design or implement them in iterative solutions.
  • Execute a facilitated discovery workshop to define the scope, as-is and to-be solution components, and high-level architecture of the solution.
  • Use both Blueworks Live and playbacks to define and visualize specific processes that the business uses on a day-to-day basis and that can support business value.
  • Be careful when changing scope and requirements. Requirements or "feature creep" are common in failed projects. Scope management is key. Not everything needs to be included in Release 1, so be selective.
  • Understand that initial design will be rough in nature. The key advantage is that early iterations will expose risks that would not be exposed as early in traditional BPM development approaches.
  • Understand that organizational culture (such as the role of IT and business) plays a huge role in determining the success of an agile BPM approach. Many organizations are not set up for this type of methodology, so you need to be sensitive to this chasm and provide adaptations where needed to support cultural aspects, and be willing to modify the method where appropriate.
  • Team members will learn along the way, both in terms of business and technical aspects.
  • Finally, we have found that a critical success factor in using these approaches is balancing iterative or agile design and development with traditional business and IT expectations and resource constraints. Exercise patience and be flexible.

Wrap-up

"A connecting principle, Linked to the invisible, Almost imperceptible, Something inexpressible." Who would have thought that Sting and The Police would articulate the benefits of an agile BPM approach?

Perhaps the greatest challenge in BPM is enabling IT and business to share a vision to deliver value based on common goals and shared understanding. Though it seems so straightforward, achieving this common understanding and shared direction is anything but simple. Successful BPM is a direct reflection of organizations working together to develop solutions. But developing solutions collaboratively is not easy; it takes commitment and direction. However, by leveraging an agile BPM approach and embracing it openly, we have found continually that organizations can optimize success with their BPM initiatives. We also consistently find that this approach helps solidify an enterprise commitment to BPM adoption as an organizational competency.

Achieving successful BPM solutions starts with an agile approach. An agile approach supports stronger business and IT collaboration on BPM and minimizes the challenges of ineffective requirement definition. By engaging business in the actual development process, design problems can be surfaced more quickly and this helps to reduce the typically long development cycles often seen in BPM. Finally, and perhaps most importantly, an agile BPM approach can institutionalize a partnership between business and IT by providing a foundation for shared commitment, role management and process ownership.


Acknowledgements

Thanks to our BPM teammates Bertrand Portier and Stuart Jones for their advice and review comments on this article. As key members in the North America BPM Solution Architecture team, they are among the best of the best. Also warm congratulations to our good friend Greg Pope on his recent retirement. Greg's work in the BPM marketplace has influenced many key clients around the world. Enjoy your retirement, my friend.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Business process management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Business process management, WebSphere
ArticleID=793628
ArticleTitle=BPM Voices: Synchronicity: An agile approach to business process management
publish-date=02152012