Business process standards
Most people in the majority of companies don’t care about standards. They simply do their jobs without thinking about the fact that their work is greatly simplified by the many common agreements about how things are to be done. It doesn’t make any difference whether we drive on the right or the left side of the road, but it’s a huge convenience that everyone within a particular geographical area agrees to do one or the other. Similarly, we all benefit by having a limited number of screw formats, so that two sets of screwdrivers will work in almost all cases.
We have discussed Geoffrey Moore’s technology adoption life cycle model in other chapters. The model is pictured in Figure A3.1. In essence, innovators take new technology from universities and labs and try to use it to make breakthroughs that will give them significant competitive advantage. They are willing to invest significant resources to figure out how to make the technology work for them. Early adopters take technologies that are a little further along and try to develop applications before their competitors do, and thus gain advantage. Like innovators, early adopters have strong technology groups. Early majority companies wait until after a technology has proven itself, and then they adopt the new technology. But early majority companies don’t expect to have to develop new technology or struggle with immature tools. More importantly, for our purposes here they expect standards to be in place. In other words, standards development at least in technological domains is an activity that is carried on by vendors and sophisticated users during the early adopter phase of the technology life cycle. It isn’t something that most companies are interested in working on—they expect it to be completed by the time the technology is ready for widespread use. In some cases technologies that fall into the chasm and disappear are those that fail to develop workable standards during their early years. The problem with this neat and orderly approach, however, is that the business process management (BPM) market is actually a number of different markets. Some like process modeling are already quite evolved, whereas others like process mining are just coming out of university labs. Thus BPM standards can be a confusing area.
The first thing to consider is the nature of the standard. Some standards are published documents, certified by groups like the International Standards Organization (ISO) and supported by national governments and large companies. Other standards are promulgated by professional associations. Their importance depends on the prestige of the professional group. Still other standards are offered by vendors who urge those using their methodologies or software products to adopt certain conventions to simplify communication among users. If the vendor is IBM or Microsoft, such a recommendation may have quite a bit of clout.
The difference between standards offered by ISO and those offered by a vendor is sometimes discussed by speaking of de facto and de jure standards. De jure (in law) standards are established by governments, standards groups, or industry consortia. De facto (in practice) standards are defined by communities without any formal agreement. Windows is the Microsoft operating system that over 80% of PC users depend upon. It is the de facto standard for PC operating systems, and any vendor that wants to sell software for PCs would be well advised to support it. In complex and rapidly evolving environments de facto standards are often more important than de jure standards, which usually take longer to develop. Put somewhat differently, if leading vendors can’t agree on a common standard they let the market decide, and the vendor that achieves the de jure standard wins.
Another important standards issue involves the availability of documentation and tests. We have already mentioned that some standards issue formal standards documents—often called specifications. Some organizations publish books that describe their standards. Recently it has become popular to speak of a body of knowledge (BoK)—an informal specification or book that describes a collection of best practices supported by a single organization in a single domain. The BoK may describe alternative ways of accomplishing a goal. Thus a BoK is not so much a precise standard, but more a collection of best practices. Thus the International Institute of Business Architects (IIBA) publishes a BoK the describes best practices for business architects.
In the same way, many professional organizations offer certification exams. In effect, these examinations are more or less rigorous tests and the certifying body usually ends up offering successful candidates some kind of certificate and the right to add some kind of initials to their business card. In some countries certification isn’t very important, but in other countries it is very important, and promotions depend on individuals passing certification examinations.
With these considerations in mind we want to spend a few minutes considering standards in the business process world today. To organize the discussion a bit more we’ll divide standards into three broad sets, according to who uses them. Organization level standards are used by business managers to assist in analyzing and organizing enterprise initiatives. Business process standards are used by business managers and business process practitioners when they undertake business process change projects. This area is the most difficult to organize because the individuals who undertake business projects vary so much. In some cases business managers and employees undertake business improvement projects. In other cases business analysts and other IT-oriented individuals undertake process automation projects. Finally, implementation standards are specific to technologies used by those charged with developing solutions to process problems. Most of the standards in this area are IT standards that structure how software is developed or how software tools interface with each other.
We can hardly consider all the business process standards that exist or are being developed today, but we want to provide a high-level overview. Obviously, we have structured the discussion and assigned standards to categories that reflect my experience. Others would surely arrange some of these standards differently, and several of the standards that we consider in one category could just as well be placed in another category. But we need to simplify a bit to provide an overview. This can be done by not considering standards offered by vendors, but by only focusing on standards offered by international standards groups or professional associations. We will mention some de facto standards that are usually only documented by vendor materials, but we will focus mainly on standards backed by published documentation or by a published BoK or certification program.
Organization-Level Business Process Standards
Organization-level business process standards are used by executives and senior business managers to help organize their overall understanding, evaluation, and management of a business’s performance. In addition, some organizations have BPM groups that report to executive committees, and they use enterprise-level standards as tools to do manager evaluations and to prioritize process interventions.
Probably the most widely used business process standard at the enterprise level is Kaplan and Norton's Balanced Scorecard approach to managerial evaluation. This is a de facto standard and predictably takes many forms. The various spin-offs of Kaplan and Norton’s approach have enough in common, however, that most companies can immediately answer “yes” or “no” if asked if they are using a Balanced Scorecard approach.
The most impressive business process standard at the enterprise level is probably the Supply Chain Council's Supply Chain Operations Reference (SCOR) framework and methodology. SCOR was developed by supply chain managers as a tool they could use to build and evaluate multicompany supply chain processes. More information is available at http://supply-chain.org.
The eBusiness Telecom Operations Map (eTOM) business process framework is another framework that is tailored for the telecom industry by the TeleManagement (TM) Forum. The TM Forum offers certification in the use of eTOM.
The Europeans have a quality standard for organizations, the European Foundation for Quality Management excellence model, which is attracting a lot of attention on the part of companies that are doing process architecture work in Europe, although it has not yet reached the United States. More information is available at http://www.efqm.org.
Another standard that is sometimes used at the organization level is the Software Engineering Institute’s (SEI) Capability Maturity Model Integrated (CMMI). Most companies use CMMI to evaluate the performance of their IT processes, in which case CMMI would be a process-level standard. A few organizations, however, use it to evaluate all their business processes to determine how the entire organization is evolving, and in those cases it can function as an enterprise-level tool. Information on this standard is available at http://www.sei.cmu.edu/cmmi. Books and certification are available. Although SEI’s CMMI is the de facto standard in the area of process maturity, several other organizations offer process maturity models, and some are more practical and easier to administer.
The US government’s various agencies rely on the Federal Enterprise Architecture Framework (FEAF). FEAF is potentially an enterprise tool, and is used that way by a few agencies. More information is available at http://www.whitehouse.gov/omb/e-gov/fea.
We’ve summarized some of the business process standards we’re considering in Figure A3.2.
Process-Level Business Process Standards
The process level is all about business process redesign and improvement projects. The standards on this level help managers, employees, business analysts, and human performance analysts change how specific processes work.
By far the most important standard at the process level is Six Sigma, another de facto standard that is defined differently by different companies and standards groups. Most of the variations on Six Sigma, however, bear enough of a family resemblance to be easily identified. Six Sigma provides a generic process improvement methodology DMAIC (Design, Measure, Analyze, Improve, and Control) and a large collection of tools that process improvement teams can use to improve processes. Most Six Sigma books suggest that Six Sigma practitioners consider using BPM, process redesign using Design for Six Sigma (DFSS), and process improvement using DMAIC. In reality, most Six Sigma practitioners are focused on DMAIC. The most respected versions of Six Sigma standards are those found in the American Society for Quality (ASQ’s) handbooks and certification exams (the ASQ is a professional association). More information on ASQ BoK and certification is available at http://www.asq.org.
Lean represents a separate methodology that focuses on eliminating waste from process flows and is now often considered one of the tools that Six Sigma teams ought to employ—so some prefer to talk of “Lean Six Sigma.” ASQ certification uses this term. However, ASQ documentation doesn’t do justice to the approach that Lean practitioners trained in the Toyota Production System employ, and there is no group that offers widely accepted Lean certification. More information on Lean is available at http://www.lean.org (the website of the Lean Enterprise Institute) or in books published by Toyota.
Almost as widespread as Six Sigma is the ISO 9000 standard. (This standard has many variations on 9000, but most people recognize it by this designation.) In essence, ISO 9000 is the ISO specification for defining business processes. Many leading European firms and governments require companies to define their processes using ISO 9000. Unfortunately, this standard has become a “checklist” item and most companies create their ISO 9000 documentation rapidly and then shelve it. There are efforts under way to make ISO 9000 more meaningful for modern business process work, but at the moment ISO documentation has little impact on how processes actually work at companies. More information is available at http://www.iso.org/iso/iso_9000.
The Object Management Group (OMG) is a standards body that is most active in the development of software standards, but it has recently become active in other areas of process modeling as well. At the organization level the OMG has published standards like the Business Motivation Model that proposes standard relationships between terms like goal, objective, and process, and the Value Delivery Modeling Language, a standard concerned with how organizations speak about the value of processes. At the process level the OMG has such standards as Business Process Model and Notation (BPMN), its new Case Management Model and Notation, and its business rule standard Decision Model and Notation. The OMG has many other standards that fall closer to implementation issues.
The OMG offers certification in all its process standards. In essence, this certification says that an individual understands a variety of the OMG's process specifications. More information is available at http://www.omg.org/omg-certifications.
The professional group within the process field that has been working on both a BoK and certification is the Association of Business Process Management Professionals. The group is international in scope. It has been slow in gaining much recognition, but now has a published BoK and is offering certification examinations. More information is available at http://www.abpmp.org.
As interest in process analysis and redesign grew in the 2000s business analysts became more active in process work. At the same time, a new professional organization, the IIBA, emerged and developed both a BoK and a certification that has been fairly popular. Although much of the focus of business analysts is on software requirements and software implementation issues, there is a core of process analysis practice that is captured in their certification program. More information is available at http://www.iiba.org.
There are several business frameworks in industry- or domain-specific areas that are useful in helping a process team design or evaluate existing business processes. Good examples are the Information Technology Infrastructure Library, a standard for IT support processes, and the Control Objectives for Information Technology, a standard for IT management processes. Both are of growing interest to companies that want to standardize their IT processes throughout the company.
Of all the standards in the process area the one that has had the most success in recent years is the OMG’s BPMN standard. Nearly every vendor has adopted this process flow notation, and it is now the most popular way to describe processes. Those who work primarily with enterprise resource planning (ERP) software still tend to use ARIS diagrams, but even these diagrams are beginning to be replaced by BPMN is many areas.
Business Process Standards for Implementation
Once a business team has redesigned a process there are various groups that can become involved in preparing for implementation. HR teams may be asked to develop new job descriptions, hire new people, or retrain existing employees. IT groups may be asked to develop software. Corporate property management groups may be asked to relocate plants, buy new trucks, or build new distribution centers, etc.
Most of the business process standards in the implementation area at the moment are IT standards. They are either designed to help IT professionals gather business requirements and design or tailor software applications, or they are designed to assure that companies can store process information in a common data format or pass models from one software tool to another. Most of the IT standards for BPM have been created by the OMG, which we have already mentioned. Other groups involved, however, include OASIS (Business Process Execution Language) and the Workflow Management Coalition. A group that is involved in enterprise architecture and indirectly in business architecture is Open Group’s architecture standard TOGAF (The Open Group Architecture Framework).
Zachman’s Enterprise Architecture is the de facto standard for enterprise architects focused on cataloging the IT assets of a company, but causes no end of confusion when people mistake it for a business process architecture standard and try to use it as a business management tool.
Finally, ARIS (Software AG’s notation and tool) is the de facto notation for diagramming ERP applications. It is used by SAP for their diagrams and has been adopted by Oracle and Microsoft. In its ERP form it’s a notation that only software developers understand, and underlines the need for a different notation for business managers. It is, however, widely used by IT developers working on ERP-based process implementations. Just don’t plan on showing an ARIS diagram of your new ERP application to your CEO.
The Future of Standards
We’ve only considered a few of the many standards being used by business process managers and developers. The variety is impressive. Key to developing standards is understanding what group will use them and what activities will be facilitated by the existence of a standard approach. When IT tries to get business people to use one of their software-oriented standards it usually leads to an unsuccessful project. Similarly, when business people provide process models to IT, developed in one of their preferred notations, it usually means that the requirements are insufficiently specified. These problems will only become more complex as companies try to figure out how to use business process management software (BPMS) tools and create BPMS applications.
We are happy that BPMN has emerged as a common language for diagramming business process flow, and we expect that other process standards will become similarly widespread in the coming decade.