Thursday, February 04, 2010

Classification of documents and processes

"Everybody focuses on document classification, but nobody ever talks about how to classify business processes. WTF?" - the considerably sanitized question I received from a client this week. Its an interesting one that maybe I will change to "How should a business align the classification of its business processes with the documents and records generated and captured within those processes?".

Back a few years, when this blog was new(er) and I had the energy to be putting some interesting thinking into writing posts with uncatchy titles, I wrote about the converging classification schemes of documents and records. This discussed how the formal taxonomies and fileplans of corporate records management might start to align in a meaningful way with the full-text indexing (Google-style search), tagging (at the time Technorati, now every blogging and bookmarking tool out there), relational databases 'indexes or titles' and a bunch of other ideas for identifying information. The conclusion was that they need to, since all these approaches have value. The cost of doing so for a business can be enormous, since adding this information can be labor-intensive.

Now add the question from my friendly client, and not only do you need to work out the meaning of corporate information, you may also need to classify the business process that produced it. The question is, if I really do go about filing documents in a structured filing system, should that be based on the content of the document, the way we need to retain and eventually dispose of the documents, the business process that produced it, the arrangement of processes documented within a COBIT structure for SOX, or some other classification that only a highly paid expert could imagine?

There are many arguments for many different approaches. We already have file plans for organizations that need to manage their formal records - the EPA for example talks about its file plan in decent depth, and how mere mortals can build on the fundamental structure within their part of the business. The focus with the EPA's guidance is to organize the records into something that allows the information to be found in the future, the security requirements and the need to archive long-term or destroy the documents according to a schedule. I don't see much business process in this.

In my opinion, a well thought out plan for storing your documents and business records automatically includes the business process that generated the information, but only if it is valuable to do so. A simplistic example based on an insurance company, could put records into this type of classification:

-> Line of business
-----> Customer
----------> Policy
--------------> Underwriting
------------------> Quote
------------------> Policy generation
------------------> Renewal
--------------> Claims
------------------> Assessment
------------------> Subrogation
--------------> Customer service

and so on...

What I see here is that at the lowest level of granularity, the business process generating or capturing the information is represented. Typically each of these items is represented by an end-to-end business process, automated or not. The details of work within the process is identifiable within these buckets (according to its own indexing scheme) and the documents must be meaningfully linked into the same work, while being available standalone. This last part is important in my opinion - the old imaging and workflow systems of years ago often held the documents within the 'work item'. If the workflow ended, the documents disappeared. Or you had to artificially tack the retention and disposition of records onto the actual business process. You could never attach more than one process to a piece of information either.

However you build out a new records structure for a business, of whatever size, the processes you run become part of it. In my opinion this can help you get to a seamless transition between what is just a written structure, and something that is actually useful for identify and finding information scattered across the business.

When it comes to technology to help simplify some of this, it makes it easier to identify if you need electronic records management, document management, report archiving, business process management, workflow or one of the many acronyms that make up a complex technology stack. Decide on the focus that helps your business work better and then ensure that fits into your information management requirements. If you try the reverse, you may not have a business worth keeping records for.

A post from the Improving It blog

To implement workflow and process automation in your business today, visit www.consected.com


No comments: