“A-B-C, easy as 1-2-3
as simple as do-re-mi…”
-Jackson 5, ABC
In 1931, a statistician named Walter Shewhart developed a framework for “continuous improvement” known as the Shewhart Cycle. The Shewhart Cycle outlined four key steps for improving processes: Plan-Do-Check-Act. A plan is developed to improve a process; the plan is implemented; the results are tested; adjustments are made and the cycle begins again. One of Shewhart’s most famous students, Dr. W. Edwards Deming, carried this concept, along with others, to Japan. The manufacturing world has never been the same.
The Deming revolution – built around concepts like continuous improvement and just-in-time inventory – had a universal impact on global manufacturing. Today, there is a new form of enterprise software that has the ability to do for white-collar business processes what Deming did for manufacturing. Delphi Group believes that “Business Process Management (BPM) is quickly emerging as the moniker for the next Killer App in enterprise software.” Believe it or not, this may actually undersell the potential impact of BPM. BPM will not just change the software industry – it will change industry in general. Just like Deming.
What type of enterprise software could possibly have such an impact? BPM is a new programming paradigm for the enterprise that leverages browser-based applications, email, global connectivity, and a maturing Enterprise Application Integration (EAI) infrastructure to deliver a powerful business-focused programming solution. A mix between workflow, EAI, and application development, BPM makes it easy for companies to (1) codify their current processes, (2) automate their execution, (3) monitor their current performance, and (4) make on-the-fly changes to improve the current processes.
Here is how it works at a detailed level. Business analysts work alongside IT staff and create a graphical flow chart of targeted processes within the organization. These graphical designs are typically done in an Integrated Design Environment (IDE) and represent the different events, decisions, and actions that are performed by employees as well as the flows of data that are necessary to perform each task. Once defined, users begin to interact with the new application. New “processes” are started by an individual (e.g., entering a new customer issue) or as the result of an event (e.g., a customer account goes past due). Actions are then passed from user to user through the concept of a task inbox, and typically the passing of a URL.
For the first time, a single user can easily “hand off” an application to another user. For instance, during an approval process, one user may initiate a purchase order. If that order is over a pre-defined limit, the order may then be passed to the task box of the user’s supervisor to await approval. The supervisor will click on a URL in the inbox, immediately see all the relevant data, and then perhaps decide to approve the order. The order may then be passed to the purchasing department, and even potentially forwarded out to the supplier.
Typically, there are six key components that exist in any BPM solution:
1) IDE: An integrated design environment used to design processes, rules, events, and exceptions. Believe it or not, many companies report huge improvements in process design merely from the act of sitting down and creating a structured definition of each process. The Holy Grail for BPM packages is for business users to be able to design all processes with zero help from IT (we are not there yet).
2) Process engine: The process engine keeps track of the states and variables for all of the active processes. Within a complex system, there could easily be thousands and thousands of processes with interlocking records and data. As such, this engine is non-trivial.
3) User directory: Administrators define users in the system by name, department, role, and even potential authority level. As an example, this directory will enable tasks to be sent automatically to “someone that is on duty in the customer service department, and has a queue of less than 3 customers”. It also allows for on-the-fly adjustments when there are personnel changes within the organization.
4) Workflow: This is the communication infrastructure that forwards tasks to the appropriate individual. This can actually be built quite simply by leveraging browsers and corporate email.
5) Reporting / process monitoring: Companies need the ability to track the performance of their current processes and the performance of personnel, who are executing these processes. This is critical to the effort of continuous improvement.
6) Integration: EAI is critical to BPM, as all business processes will require data from systems throughout the organization. Widespread adoption of Web services could minimize the amount of effort needed here.
What types of processes are companies automating with BPM software? A more appropriate question might be “what process are they not automating?” Companies are using BPM software to automate such disparate tasks as employee hiring and orientation, professional services fleet management, accounts receivable management, sales pipeline management, collaborative design, procurement, customer service and the list goes on and on. Exception handling appears to be an area where BPM really shines. Organizations have few problems when it comes to normal orders or customer requests. However, it’s the five percent that are exceptions which dominate the majority of the company’s time and resources. Also, BPM is excellent for processes that extend beyond the four walls of the organization. In these cases, partner company employees will need access and roles within the system.
There are five groups of companies that hope to profit from the BPM software opportunity. First, there are roughly 10 different “pure-play” startups with BPM offerings, including such companies as Savvion, Metastorm, Fuego, and Lombardi. The second group is workflow vendors that have repositioned themselves as BPM players. Two prominent examples here include FileNet and StaffWare. The third group is the EAI crowd such as SeeBeyond, Vitria, and Tibco, who are heavily promoting their BPM solutions as extensions of EAI. Fourth on the list are the ERP vendors who have added BPM solutions to their core functional applications. These providers will likely do well in shops that are heavily committed to one vendor. Lastly, are the platform vendors – BEA, IBM, and Microsoft. These vendors are building BPM on top of their application server architectures.
BEA has an extremely clear vision for BPM. BEA will build the technical components of BPM mentioned above (IDE, process engine, roles, etc.), and leave it to the developer community to codify specific, best-practice processes on top of their architecture. This plan will allow BEA to leverage their position as an Application Server leader. It also produces a bit of a dilemma for the pure-play companies, many of which run on top of BEA’s application server. Do these companies move upstream and focus on specific business functions or vertical solutions? Or do they risk having redundant technology with the platform vendors?
Microsoft, which is packaging its emerging BPM components in BizTalk, has a similar vision. It is rumored to be working on a BPM development environment that will take advantage of Visual Studio, the Visio flow-charting tools, and Active Directory for role management. It would also be quite obvious for Microsoft to leverage its leading position with its Outlook client whereby the “Tasks” folder would now represent queued business process tasks for each worker.
One interesting note about BPM is that it sits both on the business side of the house and the technical side of the house. Should a BPM vendor call on IT staff or a business manager? The workflow, EAI, and the platform vendors clearly approach BPM from the technical side of the house. These companies are more comfortable selling technology than “business process improvement.” The ERP vendors on the other hand live in this business world and are very comfortable talking about specific business impact in the sales call. It would appear that the pure-play vendors have more opportunity in approaching BPM as a business application than a technical application. However, they will each have to make strategic decisions as to which core components they build vs. leverage from the platform vendors.
It is important to remember that the “B” in BPM stands for business. The essence of BPM software is that it solves business problems for business users. Whether or not Web services or Corba or “.Net” is part of the underlying technology is about as interesting to these decision makers as the brand of disk brake is to most people who purchase automobiles. Understanding this critical issue is the one thing that will allow the pure-play startups to out-flank the larger incumbents. BPM purchasers want applications that are easily understood, quickly deployed, and have immediate impact. Simplicity is the key here – technology for technology’s sake just won’t fly.
Of course, the real winners here will be customers that embrace BPM to further automate, enhance, streamline, and optimize their core business processes. These processes are the core intellectual property of most businesses. And just as the level of competition in manufacturing increased with JIT, the level of competition with respect to non-manufacturing business processes will increase with BPM. Companies that lead will succeed.