ANALISTA DE NEGÓCIO

In OMG’s OCEB Certification Program, What is the Definition of Business Process?

An OCEB Certification Program White Paper
By Jon Siegel, Ph.D.
Vice President, Technology Transfer
Object Management Group
With much help from the OCEB examination authors
May, 2008

Every BPM practitioner discovers early on, through reading of related specification, books, and white papers, and listening to presentations at meetings and conferences, that there is no agreed-upon industry definition of Business Process. Instead, there are multiple definitions, each looking at the field from its own unique point of view, concentrating on its own set of concerns. It’s not a matter of one definition being “right” and the others being “wrong”; because each is useful in its context, the practitioner learns to focus on the content of the source at hand instead of critiquing the details of its definition, to maximize the insight derived from the source. In fact, the varying points of view virtually require differing definitions: The precise, formal definition required by a specification would not function well in a book or white paper by an analyst or consultant.

Our goal for the OCEB (OMG-Certified Expert in BPM) program is to certify practitioners whose knowledge and skills in BPM are both broad and deep, increasingly so as one proceeds up the ladder from Fundamental to Advanced level. If we were to adopt and use only a single, restrictive definition of Business Process in our set of examinations, our ability to achieve this goal would suffer. Necessarily, experienced practitioners are familiar with many definitions of Business Process, and able to adjust easily as the definition shifts when they move from one context to another. This is the point of view we adopted in OCEB: In lieu of adopting a single definition, we have provided, in the context of each question examining this topic, enough information to eliminate ambiguity about context and scope. Practitioners with the knowledge and experience required to function effectively at each level of certification should feel comfortable with the range and types of processes discussed in the set of OCEB examinations.
By way of example, here are a few of the definitions used in our industry:
Rummler and Brache[1], early on, declared that a Business Process was “the series of steps that a business executes to produce a product or service.” If it crosses department boundaries, it’s cross-functional. If the product is for an external customer it’s a Primary
© 2008, Object Management Group Page 1

Process; otherwise it’s a Support Process. This definition provides a good start but is so inclusive that it requires additional context to be useful.
Martyn Ould[2] defines (quoting here) a Process as a coherent set of activities carried out by a collaborating group to achieve a goal, where the “chunking” (his word) of organizational activity into processes must be driven by an understanding of the business the organization is in. Ould completes his definition by listing seven situations where practitioners need to identify and deal with processes. The situations range from support of Business Motivation modeling and analysis, through workflow management, to process improvement programs.
In their Terminology and Glossary document[3], the Workflow Management Coalition provides a useful definition, saying that a Business Process is “A set of one or more linked procedures or activities which collectively realize a business objective or policy goal, normally within the context of an organizational structure defining functional roles and relationships.” They follow up with a number of usage guidelines outlining scope, triggering conditions and output, and interactions, and point out that duration may vary widely (contrast this with Smith and Fingar, next) and that process activities may be either manual or automated.
Smith and Fingar[4] say that a Business Process is “the complete and dynamically coordinated set of collaborative and transactional activities that deliver value to customers.” They go on to assert that processes are “characteristically” (and we’re quoting here) Large and Complex; Dynamic; Widely distributed and customized across boundaries; Long-running, Automated; and more. The last item in their list, “Difficult to make visible”, seems to imply a bias towards as-yet-undiscovered As-Is processes but we’re sure they didn’t mean to exclude well-documented, mature processes from their definition. Smith and Fingar derive many valuable insights in their application of this definition even though it’s more restrictive than others.

The usage in OMG’s Business Motivation Model specification[5] is, perhaps, the least restrictive. It declares that “Business processes realize courses of action. Courses of action are undertaken to ensure that the enterprise makes progress towards one or more of its goals.” This encompasses not only the usual cyclic process (taking and filling an order, e.g.), but also a well-defined process that runs only once. For example, if the enterprise has decided to raise its process maturity from BPMM Level 3 to Level 4, the execution of the steps to do this would be a Business Process by this definition. The BMM specification points out that you’ll have to look elsewhere for details of Business Process and, by implication, for its formal definition too.
We hope you didn’t read through this paper searching for an official, definitive meaning of the term Business Process. While a more naïve person might say that is a search doomed to failure, we prefer to characterize it as incorrectly formulated: Many different activities deal with business processes, the scope of each being determined by its goals and objectives: Are you modeling, analyzing, improving, writing specifications about, or something else? Processes in scope for one activity will fall outside of scope for another.