A fork in the road

Any business analysis needs to deal with choices.
I have a simple framework for understanding choices: for any process, there should only be one choice point. If there are multiple choices involved, the process should be split into subprocesses, so that each only contains one decision point.
The reason for this is that decisions are themselves signals. If a decision is automatic, it is no longer a decision, but simply part of a process. Part of my role as a freelance data integration specialist is to remove choice from the operation of a process. Business rules, which determine the correct choice given a set of inputs, should be encoded in the tools that an employee uses, so that the right thing happens without the employee having to remember or look up what the right thing was.
Any time an employee (or you, the business owner) make a choice, an event has occurred which should kick off a business process of some kind. Since no set of business rules can cover the universe of possibilities your business faces, decisions will need to be made, and humans will have to remain part of the loop.
It may be that one of the processes that is run after a decision is the creation of a new business rule, which then is installed in the business system and constrains the behaviour of the business going forward.
It may be wise to instantiate another process which observes the result of that decision, helping you decide whether it was a good or bad decision, and allowing you to edit the business rule you are creating. This process will occur over time, so some delays and reminders will be part of this process.
It may help to consider your business as an amoeba that is growing, expanding across the universe of possible situations, slowly adding business rules and processes that will allow it to respond appropriately in more and more cases.
There are situations where a human’s role is to provide input into a process, since we are still better at perceiving and integrating information about the world, including other humans, than our robotic erstwhile overlords. Once a human has made an evaluation of a situation, one of only very few processes will kick off from that point.
Consider return clerks at Costco: they are simply following a process, since Costco’s generous return policy gives them very few decision points. Compare that to returning a dress (that may or may not have been worn) to a boutique. The clerk must decide each case on its merits, subject to business rules about timing, the presence or absence of a receipt, and the condition of the dress.
Most decision points can then be decomposed into 3 steps:
- Accept input from the environment (the state of the dress, the emotions of the customer).
- Make a determination about the input.
- Based on business rules, initiate one of several processes in response to the input.
Clear business rules mean that the employee is not forced to take responsibility for the resulting process, just for the determination of the state of the inputs (which may be black-and-white, or may require some judgement on the part of the employee).
In the absence of decision points, a process can run from external signal to exchange of value with the external actor, with no pauses or breaks required (as in a fast food purchase).
Some exchanges of value (like a freelance development contract) are all about decision points. One of the goals of this framework is to get you, the business owner, to make the decisions ahead of time. The result is that the freelancer can simply execute the process, with minimal delay and rework due to late decisions.
In my view, a decision is a natural endpoint for the process that leads up to the decision, and a natural starting point for all of the possible response processes. There may be business sense in maintaining the super-process, but the multiplicity of possible outcomes means that you must maintain a complex catalogue of acceptable inputs to prevent surprises.
Do you think that you can decompose your business based on decision points? Let me know in the comments.
