I know what you’re thinking. Blimey that’s a pretentious title what’s it all about…. Well firstly yes I agree with you, I have no defense I have tried to simplify and failed. Taxonomy is a word normally associated with categorising plants and animals. The approach of categorising tasks and roles within a business and categorising applications or the equipment used works in a very similar way.
When investigating the current state this is a very useful business analysis tool. Once I have established some common categories that will work across all the areas in scope then this can reveal opportunities to move tasks and people around, the same applies to systems or equipment, if they perform a similar function is there an opportunity to combine, reuse or move things around?
The hardest thing is starting, and by that I mean working out a classification that works and that everyone agrees with.
Here’s an example of three apparently different teams, doing completely different jobs:
- Team A – Issue and chase invoices to clients.
- Team B – Issue and follow up Sales and Marketing Material.
- Team C – Sales team that receive orders from a client.
Now what I would do in this situation, as part of my current state analysis, is to try and break down each teams processes into smaller blocks, and give those blocks a generic sort of name
- I could break Team A into the following blocks, client contact data, client account data, issue invoices, reporting, then chasing and recording, and lets say one person does each block, so they have five people, and they use one computer system called “Account” to do this.
- I then look at Team B and see that they have client contact data, client account data, issue sales material, reporting, then calling and presenting offers, and lets say one person does each block, so they too have five people, and they use a system called “marketing” to do this.
- Finally I break Team C down into receive calls, client contact data, record sales in client account data, issue sales confirmation, issue order fulfillment to an internal team, they too have five people and they use two systems, one called “sales” and the other system called “Accounting”
Now at this point I can already see some patterns but I put this information into a list so its crystal clear:
- Client contact data (3 people, and 2 systems)
- Client account data (2 people, and 2 systems)
- Issuing correspondence (invoices, sales material, sales confirmation) (3 people, and 3 systems)
- Reporting (2 people, and 2 systems)
- Chasing and recording (1 person, one system)
- Calling and presenting offers (1 person, one system)
- Receive calls on sales(1 person, one system)
- Record sales in client account data (1 person, one system)
- Issue order fulfillment to an internal team (1 person, one system)
Obviously this only an example, in the real world I wouldn’t have such neat numbers; I’d have 0.25 of a person here, 0.5 of a person there. The systems would be more complex etc, but I hope this gives an idea of the approach.
So the big question is “What do you with this information?” Well at a glance my first thoughts would be as follows:
- There could be efficiency gains in combining some jobs across teams
- It shows there is risk in the same data being inconsistent across 3 different systems
- There are overheads in maintaining 3 systems
- There is an opportunity to keep all three systems but maybe make them more integrated
So this is only one of a number tools I’ll use in my current state analysis, but it very useful in getting me away from looking at low level problems in a process and making me think much bigger.