Written by David vun Kannon    Posted February 13, 2007

David vun Kannon was one of the first Co-Chairs of the XBRL Specification Working Group and has been an Editor of every version of the XBRL Specification. He is a Director for PricewaterhouseCoopers, LLP.

In my previous post, I talked about using XBRL linkbases to represent the many kinds of relationships found in segmental reporting. In this entry, I’d like to take that idea in another direction namely, business modeling.

Typical segment reporting might look at the performance of a business unit from just a few common points of view, such as a geographic or product breakdown. But if we try to analyze a business at fine levels of detail, we eventually have to leave behind a view based on organizational units, and begin to look at the business processes taking place within an organizational unit. This is especially true if we want to understand the business at the level of what parts of the business contribute to the values reported on financial statements.

As an example, consider a large bank. You might find that a bank holding company (in the US) owns several bank operating companies. Each bank operating company might have branches spread across several states. So far, this is just a description at the classic unit and geographic levels.

If we look within one of the branches, we see a variety of business processes. For example, tellers and ATMs interact with customers, collecting and receiving cash. Loan officers discuss loans and approve funding. Each of these processes has a different effect on the financial statements of a company, whether those statements are summarized at a level for external reporting, or at the granularity of management reporting.

There are several high level models of the processes of a business. One is the Process Classification Framework available from http://www.globalbestpractices.com/ (Global Best Practices is a trademark of PricewaterhouseCoopers, LLP, my employer). Another such framework is available as part of the COSO materials. COSO, which stands for Committee of Sponsoring Organizations (of the Treadway Commission), is an organization which has developed a set of materials to help businesses understand and control their processes more effectively.

The COSO framework for internal control has become very well known in recent years. The passage of the Sarbanes-Oxley legislation in the US required companies to report on the quality of their internal control environment, and identify the framework the company is using to organize their documentation of internal control. Many companies have chosen the COSO framework for that purpose.

It is, of course, possible to extend the high level COSO process hierarchy with more company specific subprocesses. This process hierarchy is easy to map into the form of an XBRL taxonomy, just as the other hierarchies we have already seen.

A possible objection to using XBRL in this way is that there are other XML vocabularies that have been developed specifically for the purpose of business process modeling. These vocabularies include XPDL, BPML, and BPEL.

Indeed, if I were trying to document a business process at a very operational level of detail, one or another of these languages would probably be much more appropriate to use than XBRL! However, our purpose here is just to name the processes and show their general relations, not dive into the details of each process. In fact, it would be appropriate to link the process elements in the taxonomy to process descriptions in one of these vocabularies, if they were available.

Another reason to continue in XBRL is that there is so much more to add to a business process model that is not covered by the BPM specific languages. COSO and other frameworks attach nonprocess concepts to process descriptions, concepts such as objective, risk, and control. While there is no obvious way to model or document a business risk in a process modeling language, we can easily extend our hierarchy in XBRL with more abstract elements that represent the objectives of a process, the risks that may prevent those objectives from being achieved, and the controls that are put in place to mitigate the identified risks.

Here is an abbreviated example hierarchy, showing how different kinds of abstract objects are related to each other:

Bank Holding Company
–(owns)  Bank Operating Company A
–(owns)  Bank Operating Company B

Bank Operating Company B
–(operates)  Branch 1
–(operates)  Branch 2

Branch 2
–(performs)  Cash Operations
–(performs)  Loan Operations

Cash Operations
–(composed-of)  Collect Cash Deposits
–(composed-of)  Disburse Cash

Collect Cash Deposits
–(achieves)  Available for Use
–(achieves)  Safeguard Customer Funds

Available for Use
–(imperiled-by)  Employee Theft

Employee Theft
–(mitigated-by)  Videotape of Workplace
–(mitigated-by)  Working in Pairs
–(mitigated-by)  Hiring Practices

That’s enough for this post. What we’ve shown is that it is possible to use XBRL to develop a unified set of hierarchies that allow us to drill down into a business from the highest level to very granular descriptions of its processes. While this amount of detail is becoming familiar to American business, most companies have not yet moved to holding it in a neutral, flexible format like XBRL. It is at best scattered across the organization, and locked up in several incompatible formats.

Add to Del.icio.us | Digg this

This entry was posted on Tuesday, February 13th, 2007 at 6:09 pm and is filed under General, . You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.