OBI dialog illustrated

In the late1990's, a number of pioneering companies and institutions involved in eBusiness formed a standards consortium named Open Buying on the Internet (OBI). OBI's first implementation was with MIT, and beginning in 1995, the Institute defined the original pattern of operation as well as picking the initial set of pioneers through its selection of trading partners. Subsequently, the process outlined by the Institute has evolved, but it has not strayed far from its original pattern.

Below is described the OBI dialog (and proprietary approximations and extensions) in its original business context - buying "indirect materials" (MRO) such as office supplies, lab supplies, industrial gases, repair components and the like. However, the author's intent in describing the OBI "as is" is to set the stage for discussing its "repurposing." For those addressing Business Process Management (BPM) needs or various complex compliance matters, OBI is in the author's view a vital, but often "missing" architectural element - perhaps missing physically or, at least as often, missing in terms of mindshare.

Background

The original MIT scheme and the subsequently defined OBI standard addressed the serious content management problems facing buying enterprises in importing and updating large supplier-generated catalogs and other product content. The solution designed and, in various forms, now widely implemented, was to exploit the power of Internet technology to send the requisitioner dynamically to the content source rather than to bring the content to the requisitioner.

How OBI Works

A perhaps helpful explanatory metaphor likens the OBI dialog to the passing of a baseball ball between a pitcher and catcher, with the requisitioner and the requisitioner's choices of product being the "ball" being passed back and forth. Technically, this passing back and forth exploits dynamic browser "redirection" as well as http "put" and "get" services and XML document definitions or schemas.

As described step-by-step above, the requisitioner typically logs onto his or her home eProcurement system - the "pitcher," which controls the dialog. The user greatly benefits from "single sign on," because as he or she is passed from one system to another, the systems also pass the appropriate credentials. A variant - indeed, the "official" OBI standard - uses client public key (PKI) certificates to accomplish single signon.

After the requisitioner selects all the items he or she wants to acquire, he or she commits what is termed the "order request" transaction. The order request is a hybrid of a requisition and a supplier quote. As a requisition, it expresses what the user wants, while as a quote it expresses those requirements in terms of current prices, valid part numbers, and other supplier data. The supplier's system then returns the "ball" - that is, it redirects the user's browser and posts the associated order request content back to the buyer's eProcurement environment. A huge benefit attained in this step is that neither the requisitioner nor anyone else needs to rekey requisition or quote data into the buyer's system, as would often be the case if the requisitioner merely "surfs" to sellside systems.

Within the buyside system's workflow, the requisitioner and perhaps the requisitioner's management, a purchasing buyer or a cost accountant may add information to the transaction - such as cost center data or procurement card data - as well as approve or disapprove the transaction.

In the final "pitch," the eProcurement system passes to the vendor the approved purchase order. Very importantly, the buyer's procurement system also will record that transaction internally to facilitate downstream processes such as automated invoice evaluation and payment. In many cases - especially if buysiude workflow is set up for automated review and approval - the OBI sequence can take less elapsed time to progress from initial "punchout" to "approved order" than do two or three real pitches from a major league baseball pitcher.

(Note that some companies implement this dialog using middleware products and services, but these are fairly invisible IT "plumbing" and are therefore not described.)

Benefits

From a data quality perspective, the "morphing" of an OBI order request to an approved order spans one of the most problematic informational "fault lines" in the MRO procurement process - that between the sometimes informal requisition content (e.g., "I want a Dell PC") and the approved "order" which must be much more precise to be executable. Via the OBI dialog, requisitions in the form of order requests approach informational perfection because the user creates them using the supplier's own catalogs and configurators - not second or third hand replicas. Often, an OBI-generated transaction is a fit for purpose feed to support automated invoice processing or non-invoice automated payment options such as "two-way" matching, with 99%+ defect-free potential. Indeed, the process is a major Six Sigma opportunity. The process also finesses the commonplace gaps or lags in the buyside company's updates of ERP "master" data for MRO products.

Today's Situation

Today, there are various proprietary names and implementations for this OBI process. As noted above, Ariba Technologies and, later Oracle implemented the model under the name "PunchOut (R)." Ariba's name reflects the empowerment of the user to break out of the buyside catalog/knowledge base. CommerceOne implemented "Roundtrip (R)" within its own transaction variant, with its name emphasizing that the user not only is redirected out to the supplier web site, but comes back along with his or her selected content. SAP named its implementation OCI ("open catalog interface"), which suggests an infinitely (more or less) extensible virtual catalog accessible to users. No single name captures all the characteristics and potential of this model, but collectively they present a rounded portrait.

As mainstream ERP, Asset Management, supply chain and other systems become "webized" (i.e., the user interface is a browser and user dialog supports redirection), those applications potentially can support the OBI process. Therefore, implementation is no longer wholly dependent on the buyside entity using a specialized eProcurement package although there might still be advantages of doing so in the original business context.

Tho bottom line is that the OBI process in its various vendor-defined approximations is the "gold standard" for purchasing complex, configurable commodities such as laptops and special chemical mixes and for commodities that involve enormous catalogs - e.g., office supplies, books, industrial supplies, etc. Millions of such transactions occur each year. However, even in its original, focused context, the OBI process model is not used as extensively as it should be, nor has it built up much "mindshare" outside the community that implements it.

Future "Out of the Box" Potential

The OBI model has the potential to play a significant role in complex non-procurement settings, notably inter-entity information transfers. The question generically to those involved with complex, inter-entity information exchange processes (e.g., of medical records) is "what could you accomplish within a user browser session that dynamically links your workflow and multiple sources of content in a highly controllable OBI dialog? The author certainly thinks that the answer is "a lot", based on extensive experience in the MRO world. There is a far greater hope of implementing a fast, convenient way of implementing effective filtering - getting users access to what they should access, while filtering out inappropriate access requests. For more on the requirements that could be addressed see "need to know."

It is ironic that some companies and institutions are struggling to address high priority compliance, privacy and security issues by using less sophisticated and appropriate process models, even though they are practitioners of OBI either as buyers, as sellers or both. These entities may instead use information exchange models based on system-to-system XML exchanges - whether synchronous or asynchronous. These can work well for "production" ("direct materials") trading relationships, as does classic EDI. However, many compliance-intensive information exchanges better fit OBI, because OBI incorporates both human judgement and workflow into the exchange process far more easily and naturally.

Therefore, the author suggests pressing the OBI model - perhaps with modifaction - into duty for often high priority BMP and compliance-intensive needs, within an overall context of exploiting XML - see "strategic impact." The "with modification" is TBD.

Fulton Wilcox
Colts Neck Solutions LLC