If you’ve read any of my previous articles on the Kaboodle Classification Framework (KCF) then you’ll know that development of the Information Architecture (IA) relies on 8 principal tasks. If you don’t know what the KCF is then here is probably not the best place to start and I would encourage you to go and read the overview and then return in due course.
In this article I’m going to focus on the first of the 4 tasks in the Conceptual part of the KCF, namely the development of a Business Classification Scheme (BCS).
If you’ve ever talked to a professional records manager then they know all about the BCS because it is vital component of how they can apply information management policies for retention and disposal on important documents (commonly known as records).
The National Archives of Australia defines a BCS as:
“A conceptual model of business activities that identifies business functions and their associated activities and transactions”
Now, don’t get hung up on the Australian thing (a BCS it’s nothing specific to Australia) and don’t get hung up on records management thing either, it’s just that records managers know how to classify information, that’s what they do for a living. So I make no apologies here for steeling other peoples ideas – especially when they are good ones.
The purpose and function of a BCS and why it is useful
As part of the KCF, the purpose of the BCS is to provide a functionally based classification system such that all information products created or managed by the business can be classified in such a way as to indicate their purpose, function, scope and so their relative importance to the business.
In due course, we will see how the BCS gets translated into metadata using the SharePoint Managed Metadata Service (MMS). Having the BCS implemented as managed metadata is useful because:
- It greatly assists with search and retrieval process.
- It enables relevant content to be automatically surfaced within a functional context such as in a specific page in an information portal
- It can be used to drive information management policies for retention, archive and disposal (the records management thing)
- It fosters good information governance
- It helps an organisation to develop a consistent and universal understanding of meaning – semantics
The term “information product” is used deliberately, as the BCS makes no assumptions about the format or media in which the information is stored. An information product might be a Word or PDF document but it could equally be a fax, a video clip, a wiki page, an email or a blog post. Hell, you can even class a Tweet as a document as anyone who follows Donald Trump on Twitter can attest. And it can reside either physically (as paper or a DVD for example) or electronically on some kind of storage media (hard disk, storage area network or the cloud).
The Structure of a BCS
A BCS is a hierarchical structure of managed terms that describe the set of functions executed by the business or organisation. The BCS defines broad business functions at the top most level in the hierarchy which become more refined and specific at lower levels. In other words it’s a taxonomy to describe business processes.
There are essentially 3 layers in the BCS, namely:
Function > Activity > Transaction
The reason why a functional taxonomy is better than say an organisational based taxonomy (one based around organisational business units such as Divisions, Departments and Teams) is to do with its robustness. What an organisation does, tends to be static or slow to change at least, whereas a business can go through restructuring much more frequently, at the whim of a newly appointed CEO.
Business Function
The Business Function layer describes the broad functional area to which the information products relate.
Standard Models
As a veteran of almost 20 years of service as an officer in the British Army I can confirm that the military have had this functional grouping sorted for some time now and it is commonly referred to as the J-functions (J standing for joint meaning a HQ involving land, sea and air operations).
There is a leadership function for Command and Control and 9 J-functions as shown in the Military Classification Scheme (MCS) below.
This is not a précis on how the military works but it is easy enough to translate this into common business functions such as those in the example of a standard BCS shown below.
Please note that the above diagrams are not intended to provide the actual Business Functions (unless your customer really is a Military HQ) but rather as an example of how the business might be classified into such functional groups.
This work of defining the actual Business Functions will be organisation specific and should be analysed, discussed and reviewed by key stakeholders in the project, including senior management, until agreement is reached on the number, scope, title and description of each functional area.
Business Functions are intended to be a broad categorisation of the functions performed by the business and as such there is a balance to be reached between what is a meaningful separation of functions without being too specific at this top level of the classification.
As a guiding rule the number of Business Functions should be between 5 and 12. Any less than 5 and you will be too coarse and anything greater than 12 is likely to be too refined but be pragmatic and don’t get too worried if you end up with 13 functions or even a few more, so long as it makes sense to the business context.
How to develop the Business Functions
But how do you come up with the Business Functions? Here’s what I recommend:
- Start with a standard model in mind (like the examples shown above)
- Review the organisation chart of the business and see how readily you can map that to the standard model. However, be wary (very wary) of just implementing the org chart as we are after functional groups here and not organisational groups. Still, the reality is that there is usually significant alignment between the two, so do look at the org chart in detail.
- Rationalise and consolidate and map to the terms used by the organisation.
- Run a workshop to see if you’ve got it right.
- Document the functions and get it signed off as a project deliverable.
An actual example
Sounds easy doesn’t it and conceptually it is. But as a business consultant you have to learn to listen and when to speak up and when its ok to let things lay as they are. The following shows the Business Functions of a real customer (a manufacturing company although they’re not really called ACME of course).
In this particular project the Business Functions were already squared away with management and signed off before I even met with the customer and so there was no way I was going to push for a rehashing of that work even if I wanted to.
If I were to nitpick, I would have liked to have seen it less aligned with the organisational structure and I would have maybe strived to fuse a few of the functions together. For example:
- Manufacturing and Engineering (both departments) could be generalised to Production.
- Maintenance and Supply Chain could be merged into Logistics.
- Continuous Improvement, Quality and Regulatory Compliance might all be grouped under Quality Assurance.
However, the consultant who did this work had been with the organisation for a year and had obviously accumulated extensive knowledge about what would work for the business so I wasn’t about to upset any apple carts, especially as there is no good reason to do so, as these functions will work just fine, even if there are 13 of them. Did I mention about the need to be pragmatic?
Business Activities
The Business Activity layer of the BCS defines the actions performed within the parent Business Function.
Activities and Sub Activities
Business Activities can further divided into Sub-Activities if it makes sense to do so. This is why it is considered a layer in the BCS rather than a single level in the BCS hierarchy.
The idea of the Business Activity layer is best explained by examples. Consider that the business functional review, results in a top level function called Resource Management. This might further be sub-divided into high level Business Activities of:
- Human Resource Management
- Buildings and Facilities Management
- …and other high level Business Activities in the Resource Management functional area
Human Resource Management might be further refined into Business Sub-Activities such as:
- Recruitment
- Staff Retention
- Remuneration
- Pay
- Salary Sacrifice
- Novated Car Lease
- Mobile Phone
- Training and Development
- …and others
So you start to build up is a picture like that shown below.
How to develop the Business Activities?
But how do you come up with the Business Activities? Here’s what I recommend:
- For each Function identify the parts of the business which perform that function
- Organise a series of small workshops and (if resourcing permits) one-to-one interviews with people who work in that Function
- Elicit the key business processes and sub-processes that are executed within the Function
- Add these processes and sub-processes as Activities and Sub-Activities to the BCS
- Move through the organisation until you have identified uncovered all that the business does and have plotted each process as an Activity/Sub-Activity in the BCS
- As you go through this business process analysis, take a note of the technology that is currently used to support the activities especially the technology used for information production and storage.
This is not Business Process Review but…
Although the BCS (and the KCF for that matter) or not intended to be tools for business process review and re-engineering that doesn’t means that you shouldn’t look for redundancy, duplication, inconsistency and just plain stupidity during the process analysis.
It’s not uncommon to discover that 2 departments are essentially doing the same job! Now, it may not be your job to sort these issues out but if you discover them (and you will discover them) then I think you still have a duty to point them out. Sadly, too often the business will agree with your observations that things could be run better but then don’t implement any change.
A quick side-rant on PiSSUp Cycles
The number of organisations and processes within them that execute unnecessary Print > Sign > Scan > Upload cycles is truly staggering. I call these PiSSUp cycles. Sometimes these PiSSUps are genuinely required but more often than not, things are done this way because:
- That’s the way the organisation has always done it.
- The policy says we need a “wet signature” when actually the policy says no such thing or if it does state that then it hasn’t been reviewed for 10 years or more.
- Electronic Signature or Digital Signature technology is expensive and difficult to use and we’re not sure it would stand up in court anyway.
BTW, having admin assistants paste jpegs of the boss’s scanned signature into document is not an eSignature and is no way to avoid a PiSSUp cycle. Even if the intention was good, the execution is truly flawed.
I think I’ll come back to eSignatures and Digital Signatures in a separate post as I have quite a lot to say on the matter (as you may have guessed).
The reason I hate PiSSUps so much is:
- They just waste so much time
- They waste resources (paper, ink, storage)
- The cause duplication (and duplication is root evil behind huge information f***ups). When you execute a PiSSUp cycle you create at least 2 duplicates of the original, namely the printed out and signed hardcopy and the subsequently scanned version.
- Unless the business process is very well governed (rarely the case) then redundant duplicates aren’t destroyed which means that they are left hanging about to cause problems with Currency and Consistency and we now have to manage information security in 3 places.
- They always leave you with a sore head and a nasty taste in your mouth (different sort of PiSSUp maybe) but metaphorically still true.
When you discover PiSSUps, and you will find them, do all that you can to encourage the organisation to take proactive steps to eliminate them wherever possible.
Rant over!
Transactions
The leaf nodes of the BCS represent Transactions that occur within a parent Business Activity. A Transaction can often be identified by the collection of information products that relate to a specific outcome, event or action.
The above diagram is incomplete but shows enough of the Human Resource Management Activity in Resource Management Function to demonstrate the key idea.
Information products that support Transactions are represented as leaf nodes in the BCS. So a Vacancy Notice, Job Description, Job Offer are key information product used in support of the Recruitment Activity. The Transactions which correspond to these products might be:
- Create or revise a Job Description
- Prepare, approve and publish a Vacancy Notice
- Prepare, approve and dispatch a Job Offer
How to develop the Transactions?
But how do you come up with the list of Transactions? Here’s what I recommend:
- For each business process conducted within each Business Activity draw up a list of the information products created or used in the execution of that process.
- The list of information products used should be elicited from stakeholders in the process.
- Reverse engineer the list of information products to get to the Transactions descriptions..
In reality, I often find it counter-productive to get hung up on providing Transaction descriptions and so tend to jump straight to hanging document types from Activities and Sub-Activities. I think this is fine so long as you understand that the BCS is about defining a functionally based taxonomy and not about document type analysis – which is the next task in KCF and the subject of my next article.
Kaboodle Software 
1 comment