Continuously improving business processes with methodologies, technologies and the power of people

Business Process Improvement

Subscribe to Business Process Improvement: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Business Process Improvement: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Business Process Improvement Authors: Prince Kumar, Dana Gardner, Continuum Blog, Automic Blog, Liz McMillan

Related Topics: SOA & WOA Magazine, Business Process Improvement

SOA & WOA: Article

The Missing 'Discovery' Link to Successful Business Process Management

Process improvement based on user behavior, not estimates or anecdotes

Every organization is under pressure to deliver tangible business benefit through its IT projects. This point is illustrated by the fact that almost all IT projects are justified based on the ROI they will deliver. However, very few organizations follow up and review all projects based on the ROI they actually provided. While the reasons for this aren't clear, one compelling, well-documented statistic is that on average only one out of three IT projects will be successfully completed and deliver the ROI they promised.

If we dig deeper into understanding why two-thirds of projects fail, the good news is the root cause is not due to the deficiencies in technical capability. The tools the IT staff has on-hand become very robust and well understood over the last 30 years. Instead, the root cause of these failures is simply due to a lack of understanding of the business process that the project was supposed to improve. In spite of the fact that on average, 70% of an IT project's budget is dedicated to understanding and documenting the business process through requirements, analysis, design, and testing the process. Just like a sick patient at the hospital, you can't begin treatment without an accurate, effective diagnosis.

The traditional IT methodology for documenting the business process has several significant limitations. First, it never captures all of the nuances of the business process. The old saying "The devil is in the details" is true, and every process has a seemingly endless set of exceptions, variations, and deviations that only become apparent as they occur, hopefully in testing, invariably after the system is put into production.

Second, the process is often assumed to be repeatable across all users. Unfortunately, this is never the case. Best case, users just have different habits; worst case, different user groups have significant differences stemming from the process's core requirements.

Third, the business process is a snapshot in time of the process. With the speed of business today, business processes are in a continuous state of transition. One key reason that shorter, small projects succeed more than longer projects is that the business process doesn't have time to evolve from the assumed, analyzed process.

Most business processes today are technology-enabled and users leave electronic footprints of the process through the IT assets supporting the process. By examining the footprints the users leave as they execute their process, the business process can be automatically discovered and documented in near real-time.

Business Process Discovery (BPD) is an emerging field that discovers the business processes based on examining the activities of the users on the IT assets that support the business processes. Coming at the business process "bottom-up" from the detailed facts of instances of the process provides a detailed depiction of the business process, complete with all the nuances of that process, including detailed statistical information on how often different variations of the process are executed, how long it takes, what data conditions give rise to process variations, what variations there are between different users or groups, etc. And, since BPD is an automated process, the business process can also be kept updated on a perpetual basis.

To illustrate BPD, consider a mainframe-enabled business process of order management. Order management in itself is a fairly large and ambiguous process; there are multiple aspects and organizations that could be involved ranging from order entry, call centers, credit management, etc. A traditional approach would interview representatives from each area and paint a process map that everyone could agree on. Alternatively, with BPD we'd watch how each user in the organization interacted with the mainframe and let the business process emerge from the data. (Figure 1)

If we were to create a session file of every keystroke and every screen for every user in the organization and weave those files together into a process map we'd be able to see exactly how users are interacting with the system to achieve the process. We'd see what screens transaction users are using, how often they are using them, and how consistent the process is between users. Out of this picture, we'd quickly see the different sub-processes of order entry, call center, and credit check. We'd see the various data conditions that trigger different process points, e.g., order greater than credit limit creates a credit approval process. And, perhaps most importantly, we'd see the wall clock time and the process errors that you can't get from the interview process. Those are the places in the process that require the most user time, where users are struggling with the existing system. (Figure 2)

The BPD approach provides a near real-time, complete, and accurate view of the existing business process. This fundamentally changes the economics of IT projects, no longer is 70% of the budget required for analysis and design. This leads to shorter, cheaper projects.

This also leads to a different way to approach business process improvement. The traditional approach of an enormous, risky business process re-engineering effort requires that extensive work be done on process mapping, process analysis, and making large one-time changes. BPD, however, creates an environment where it's natural to make smaller incremental process changes that yield immediate return, and repeat the process in a continuous improvement cycle. This creates an environment where the business users are continuously seeing benefits and most IT spending is on creating benefit, not on documenting business processes.

Traditionally, small incremental projects were difficult to execute not just because of the challenges of traditional process analysis but also because of the inflexible IT architectures that made it difficult to make incremental improvements. Service Oriented Architectures (SOA), however, are fundamentally changing that inflexible paradigm. SOA lets organizations rapidly adapt and incrementally improve their processes. This architectural change in the way IT systems are organized and deployed removes the technological constraints to an iterative, incremental improvement cycle.

However, the key to success with SOA is to be able to effectively define the appropriate granularity of the business services. BPD complements a SOA approach to solve this problem by having services emerge from this bottom-up analysis of the business processes and implementing those services that are required incrementally as part of process improvement initiatives.

Having a near real-time view of your current business processes yields dramatic returns beyond improving application development. Once the typical business process is understood, being able to monitor that business process for deviations introduces a proactive business process monitor that has immediate applicability for IT operations management as well as compliance and security. A self-documenting business process allows IT staff and business users to be on the same page and help-desk support staff can immediately understand the business process or the deviation from the business process of a specific user. This allows a proactive investigation and response to the deviation, whether it's a user-training issue, systems-availability issue, or just an unusual business situation driving the workflow.

Perhaps the best thing about BPD is that getting started is easy and extremely low risk. The promise and benefits of BPD is to be able to derive business processes quickly, easily and automatically based on an examination of business user behavior. In our experience, we find that in a couple of weeks, we can target several business process improvement opportunities based on the detailed process maps that our BPD tool provides. This creates quantified process improvement opportunity based not on estimates or anecdotes, but on the solid facts of user behavior.

More Stories By Stuart Burris

As president and chief technology officer, Stuart Burris is responsible for the overall management of OpenConnect as well as its technology vision and strategy. He joined OpenConnect in 1990 and has held a variety of research and product development roles, most recently as vice president, research and development. During Stuart's tenure at OpenConnect, he has been instrumental in the development of the architecture for the company's industry leading Mainframe-to-Web products used by thousands of companies worldwide.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.