BPM Voices: BPM and Lean -- a powerful combination for process improvement

This article describes how to achieve quick wins for process improvement by combining Lean methodologies with the capabilities of IBM® Business Process Manager (IBM BPM). It provides an introduction to the key principles and benefits of lean process improvement, followed by an approach showing how Lean benefits from IBM BPM to provide key business value with limited effort. This content is part of the IBM Business Process Management Journal.

Philipp Schume (pschume@us.ibm.com), Senior Solution Architect, IBM

Philipp Schume photoPhilipp Schume is a BPM Solution Architect for the Smarter Process Center of Competency. He has many years of experience leading custom application development and business process management projects.



28 August 2013

Also available in Portuguese

Lean - what it is and how it works

With a history of more than fifty years, Lean thinking focuses on value for the customer by eliminating waste in an end-to-end process. It establishes flow and implements a "one-piece" pull system. It strives to achieve perfection through continuous improvement.

Figure 1 provides a concise summary of Lean's key principles:

  1. Business value is key.
  2. Identify all steps (value added and non-value added).
  3. Align the steps in sequence to establish flow.
  4. Implement a pull mechanism to work downstream.
  5. Eliminate waste through improvement and optimization.
Figure 1. Lean principles
Lean principles

Lean process improvement provides many tools and methods to detect and eliminate waste. However, implemented Lean projects are often challenged to quantify the effectiveness of the changes and to continuously improve the process using process metrics and analysis.

The seven prominent wastes of Lean, also known as TIMWOOD, are a common denominator found in many business processes. As shown in Figure 2, these are:

  1. Transport time of information between areas (offices, desks)
  2. Inventory (too much, too little, or erroneous information)
  3. Motion of workers
  4. Wait time between process steps
  5. Over-processing, which places high attention on low-value activities
  6. Over-production, which places the priorities on the wrong activities, drivers, or values
  7. Defects or activities that are not directly related to needs
Figure 2. Seven wastes of Lean
Seven wastes of Lean

When a business process is analyzed using the Lean methodology, all process activities are classified into value-adding (VA) and non-value adding (NVA) activities. Typically, more than 50% of activities are non-value adding, or activities the customer is unwilling to pay for. These NVAs are further analyzed and summarized into the seven waste categories to assist the project team in finding a Lean solution for the future process.

Key challenges

Although Lean provides excellent methods for process improvement, it is unable to easily provide visibility into a process and quantify the extent of the improvement. Past experience with Lean improvement projects reveals that many clients have neither sufficient process automation nor real system integration to completely "lean" their processes. This situation creates additional process activities, which Lean views as operational waste. However, these additional activities usually stay in the process after the first Lean improvement cycle. Lean focuses on short-term process changes, while IT works on mid- or long-term improvements.

More importantly, the lack of adequate measurements, missing targets, and key performance indicators (KPIs) are some of the biggest challenges during the Future State (To-Be) testing and implementation in many process improvement projects. An effective process measurement system drives continuous improvement to generate the expected improvements, and monitors the process for staff and management. What gets measured gets improved!


How business process management complements Lean

Companies improve their processes in a variety of ways. While it is generally understood that the success of BPM lies in the cooperation of business and IT, BPM also acts as the glue between the two. We often see drivers for process improvement coming from both directions.

  • Bottom-Up is an IT-driven initiative to automate processes or replace older BPM technologies, or both.
  • Top-Down is the preferred approach to achieve process improvement through initiatives such as Lean or Six Sigma.

Both approaches are associated with three value-adding types of projects:

Type 1
Pure improvement (Lean/Six Sigma) of the operational procedures. Neither process diagrams nor anything related to technology results from this approach. However, operational procedures improve by 10-20%. Type 1 projects are driven by goals like improved customer experience, decreased cost, and increased volume. These measures exclude continuous improvement.
Type 2
Process improvement with process control and automation. This includes simple UIs, screen flows and dashboards. The approach results in an additional 10% or more on top of the values gained from using the Type 1 approach in a quick-win Release 1, which I'll discuss in more detail later. Including full automation and integration in Release 2, an additional 10-20% is expected to be realized.
Type 3
Bottom-up, technology-driven process re-engineering. This includes process analysis and improvement phases as per BPM methodology, but no full Lean or Six Sigma. Improvements up to 30% or more can be realized.
Figure 3. Types of process improvement
Types of process improvement

While Types 1 and 3 are very well-known approaches, Type 2 offers a new perspective on things. Type 2, which is designed to deliver quick wins to a process improvement initiative, is subdivided into two releases. Standard process improvement with BPM process control in Release 1, and more detailed UI, data and integration development in Release 2. Lean projects often suffer from complicated or large efforts to measure the future-state process (To-Be process). IBM BPM, with its strength in rapid design and development and strong support of agility, can solve these issues with its packaged capabilities and, if necessary, customized implementations for measurement and tracking.

By focusing on simplicity and out-of-the-box functionalities in Release 1, IBM BPM allows process control and measurement with relatively little effort. It provides:

  • Simple data models that are created solely to help prioritize tasks (in the task list) and to provide basic case information (on the UI).

    Instead of having a task list (as we know it in BPM), paper processes often consist of a stack of files. Every process participant works the stack from the top down. This may even result in changing the order of the cases considerably, since the topmost case shifts to the bottom after the first activity. With BPM, out-of-the-box dashboards are easy to use and provide valuable insight for management.

  • Simple load balancing and effective routing ensure efficient and appropriate staffing.

Release 2 takes the backlog of user stories, which were not implemented in Release 1. It gets planned similar to a regular BPM implementation project. As usual, BPM projects are time-boxed. Therefore, depending on the needs of the customer, you can either aim to support the Lean Roll-Out or Sustain phase (described later) with the next BPM release. This includes more functionality on Coaches, integrations and data. However, the time for Release 2 is completely flexible and can be adjusted to the customer's funding capabilities. Although it is recommended to implement Release 1 and 2 in a back-to-back manner, even with months of delay between them, Release 2 is able to rapidly provide high-value capabilities to the process.


The combined methodology

The combined Lean and BPM methodology follows the Lean process improvement methodology while incorporating the BPM lifecycle. Figure 4 depicts the Lean process improvement process in orange and the standard BPM development lifecycle in blue.

Figure 4. Combined methodology
Combined methodology

The vertical arrows mark integration points between both methodologies. I'll describe these in more detail in the next section.

Lean assessment / BPM analysis phase

Lean process improvement happens traditionally over the course of sixteen weeks, beginning with mobilization and ending with roll-out planning. The first four weeks consist of the Lean Assessment phase, in which the current-state and future-state processes, in addition to their transition components, gets understood and devolved.

After the third week, the future-state process gets designed. This is the point at which the BPM project lifecycle phase of the process begins. During the Lean future-state workshop, a BPM analyst joins the team to contribute automation and software support perspectives to the discussions and to gain an understanding of the future state design.

The core responsibility of the BPM analyst lies in capturing the future state process in Blueworks Live, similar to the way it would be performed in a traditional BPM engagement. The BPM analyst also fulfills the usual tasks, such as writing user stories and defining integration points.

Using this information, a Playback 0 is performed. This has a focus on the Lean process improvement activities, but is supported by a Blueworks Live automated flow.

Figure 5. Detailed methodology
Detailed nethodology

In conjunction with the Lean Assessment and BPM Analysis phase, the overall project manager will create the backlog for the BPM Release 1, thereby initiating the cycle of agile iteration and release planning.

Release 1

The goals of Release 1 are to keep it simple and out-of-the-box to provide quick wins for Lean.

After Playback 0, Lean's implementation phase begins with the following steps:

  1. Step 1: Three weeks preparing the pilot
  2. Step 2: Four weeks executing the pilot
  3. Step 3: Three weeks planning the roll-out

The three weeks of pilot preparation mark the development phase for BPM. Once the Lean pilot goes live, it will already be supported by BPM, which allows for the immediate availability of measurements.

This ends in a Playback 1 (or Playback 1+), which focuses on:

  • End-to-end process flow, which includes exception paths.
  • Simple UIs, which contain basic business information that enables correlation to a particular client, case, and so on. They include commenting and collaboration functionality and out-of-the-box document management controls. The main goal for the UIs is to tell the user what to do (as in "perform operational procedure x") and for whom (for example, customer y).
  • Simple data flow, which contains only the basic information necessary to identify the case and enable prioritization of tasks.
  • Service-level agreements (SLAs) or KPIs and escalations
  • Measurements of process improvement relevant KPIs (usually waiting times, number of executions, execution times, and so on).
  • Dashboards and reports to visualize measurements. These should be performed using out-of-the-box capabilities such as dashboards or optimizer reports.

Again, the important principle is "Keep it simple and out-of-the-box" to provide quick wins for Lean.

A typical schedule for Release 1 looks like this:

  • Week 1: Process flow and UI
  • Week 2: Data (prioritizations) and tracking (if out-of-the-box KPIs are insufficient)
  • Week 3: Test
  • After week 3: First production release gets delivered by performing a Playback 1.
  • After week 4: BPM lifecycle enters the continuous improvement phase, which supports any important changes that may occur from the Lean Roll-Out and Sustain phase.

Playback 1 differs from the standard at this point, since exception paths are taken into consideration. This happens by sacrificing a considerable amount of UI functionality. Keep the simplicity of the development in mind. This ensures that a simple production release can be provided after three weeks. At this point, the value lies in the improvement, visibility and measurement of the process, and not yet in the user experience (the UI).

You need to create reports because sufficient information is not provided by Optimizer or Dashboards, so in Week 4 reports are added to the schedule. Because performance information will already have been captured, the reports do not need to be provided at the time of Playback 1. No harm will result if reports are produced after-the-fact.

BPM Release 2

After Release 1 is delivered, Release 2 would ideally commence right away. It occurs in parallel with the Lean Roll-Out phase and is time-boxed to meet its transition into the Sustain cycle.

Alternatively, Release 2 can be deferred to a later point in time. This is technically possible, but it is recommended that you follow Release 1 immediately in a process improvement program.

Release 2 consists of Release 1 with all high-value user stories that can be implemented within the given timeframe. Again, the BPM implementation follows the standard methodology including all playbacks (starting from Playback 2) as well as the process improvement team and feedback from end users of Release 1.

After Release 2, you progress to Release 3, which includes all remaining user stories, which are likely to have a stronger focus on integrations.

In following this approach, you can deliver to the client:

  • Improved operations with quick wins for Lean (control, visibility and measurement) in Release 1 (within 7 weeks).
  • Improved usability, acceptance, and additional value for the end users in Release 2 (within 16 weeks).
  • Full process automation in Release 3.

Staffing

In Figure 6, Lean roles are aligned in orange and BPM roles in blue. A dashed line signifies partial involvement (as needed); a straight line indicates 100% commitment.

Figure 6. Staffing
Staffing

As you can see, very limited BPM involvement is necessary for a Type 2 Release 1. This indicates that the costs involved for Release 1 are relatively low. Release 2, however, complies with the standard staffing model for BPM engagements.

The Lean team involvement follows standard Lean staffing. Once the team is in the Sustain phase, frequent checkpoints and meetings must be performed. However, the overall effort does not increase considerably from a Lean or line of business point of view.


The BPM value proposition for Lean

The key values IBM BPM provides for a Lean initiative are:

  • Process measurements
  • Performance visibility
  • Process control and management
  • Continuous improvements

As the adage goes: "You can't improve what you can't see." Along those lines, BPM core functions that are great value for Lean are:

KPIs
These come out-of-the-box with every activity and for the overall process. One of the main goals of Lean is to eliminate waste, and KPIs are a key driver to identify these.
SLAs (including escalations)
SLAs ensure that the value a process should provide is actually provided. SLAs enable visibility and the ability to act on broken SLAs (for example, with escalations).
Dashboards
Dashboards enable instant viewing of personal, process, or team-related performance for task statuses and pipelines.
Task lists
Many companies work with the old pattern of work distribution (a manager assigns work to people on his or her team). A BPM task list instantly improves this using a pull mechanism. Furthermore, optimized routing and load-balancing can easily improve the overall performance of the process.
Optimizer and historical reports
Simulations based on actual historical data, as well as projected data, can be critical for a process improvement initiative. They also provide useful insight into all levels of KPI performances.
Visibility
Providing visibility of a process to the users, in such a manner that they are able to see where each instance and path occurs, provides a heightened understanding and level of ownership for process participants.

Conclusion

Lean (or Six Sigma) and BPM complement each other by providing high value with low effort. BPM solves key challenges for Lean or Six Sigma initiatives that make these initiatives even more effective, without impacting timelines or creating high costs. BPM is not only technology, but brings process improvements to the next level.

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. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. 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=942276
ArticleTitle=BPM Voices: BPM and Lean -- a powerful combination for process improvement
publish-date=08282013