How I analyse for opportunities and problems
Over the last ten years I’ve had many colleagues and clients who have shown an interest in understanding more about how I carry out analysis of business opportunities and business problems. My approach has changed little over this time – if anything I’ve just honed the short-cuts rather than find any need to alter the core approach.
In this first post, and in the next couple, I’ll attempt to lift the lid and share the most important aspects of this work.
Part One – Terminology
If terminology doesn’t reflect the language already in use in organisations I think it should be avoided if possible. A shared understanding of the main words used in opportunity and problem analysis is important for discussing the findings, the issues and improvements. Occasionally I’ve had to interpret for consultants using arcane terms like “Process Levels 1,2,3,&4” where they are simply not understood by the customer, let alone the downstream delivery teams. They also force learning on key stakeholders who have better things to do with their time.
I use the following five simple terms which provide simple contexts for structuring my analysis and for modelling observations and data. I’ve used these successfully for many years. They’re easily understandable by organisational staff and management.
Note that I often drop the qualifying words in brackets when my audience demonstrates an understanding of the terms.
(Business) Process: this describes the workflows required for the handling and execution of a particular business event and the associated business goal. A business process can incorporate many people and can be asynchronous over a potentially extended period of time, (e.g. supermarket online shopping offers, purchase, through to fulfilment).
(Business) Task: a logical major step deliverable occurring in the context of an overall business process. A task can be delivered over an extended period of time in an asynchronous manner, by multiple people (e.g. collection and packaging of supermarket goods for delivery).
(User) Activity: a logical goal-driven function carried out by a single person (e.g. frontline customer service advisor: handle failed online customer payment). An activity can utilise multiple tools and take place in a non-synchronous way over a period of time. Note that a person will typically have many activities to carry out within any given role.
(User) Interaction: a synchronous unit of work carried out as part of a persons activity on a specific toolset e.g. using computer software, a mobile device, machinery, or manual work (e.g. record new credit card details via computer). This includes the detail of discrete person-tool actions that takes place in the course of an interaction (e.g. enter expiry date in the mandatory computer website form field with format mm/yy). For this reason interactions can utilise hierarchies of actions such that a core set of key interactions may hide the complexity of user actions for some levels of discussion whilst for other purposes the detailed actions can be discussed as necessary. Actions can be sequential, parallel, mandatory and arbitrary.
Operation: an event, or group of events, applicable only to mechanistic or computerised toolsets that have no person-facing interactions (e.g. create a new database record and queue for fulfilment: customer name, customer ref, date/time, shopping products ordered, delivery address, etc.).
These terms are agnostic to the methodology being used, whether it is six sigma or another approach. They also carry across into design to provide useful context e.g. when designing for an activity we are focussing on an individual user’s needs, rather than the business, or the technology.
In the next blog, Part Two – Quick Immersion, I’ll talk about how I handle complexity to get accurate insights into the opportunities and issues around the way an organisation is working.
Leave a Reply