We treat a business as a system for making decisions. How we rank the decisions worth improving, choose the method, judge whether the data is useful, and capture the judgment of experienced people.
A business is a system for making decisions. The products, the plants, the software, and the people all exist to support them. When the quality of the decisions that matter improves and holds, the business improves. Adding technology to decisions nobody has examined rarely changes anything.
So we start by mapping the decisions that set a company's results: who makes each one, how often, on what information, how long it takes from trigger to action, and what it costs when one goes wrong.
Every day people decide what to buy, make, schedule, quote, approve, repair, and ship. No single instance changes much. Together they set gross margin, working capital, service level, and capacity, which is why we treat the decision as the unit we are trying to improve.
We rank them by how often each decision is made, how much money it moves, and how much the method varies between the people making it. A decision made many times a week by a dozen people, each with their own approach, usually holds more recoverable value than one made twice a year by executives who already give it their full attention.
The decisions worth the most are usually the ordinary ones: made often, by many people, with no agreed method.
For each decision worth working on, we write down the trigger, the person who decides, the information they use and which system it comes from, what they do when that information is late or missing, the elapsed time from trigger to action, how often the decision turns out to be wrong, and what a wrong one costs.
That description usually names the constraint before any technology is chosen. Sometimes the data arrives the day after the decision has to be made. Sometimes an approval step adds more delay than the analysis it protects. Sometimes the person deciding does not have the authority to act on the answer, so a better answer changes nothing.
Only once the decision is described do we choose how to improve it. The question is which method is the simplest one that moves the number: a rule, an existing report delivered earlier in the week, a changed threshold, a statistical model, an optimizer, or a learned model. A good share of the value we find sits well to the left of machine learning, and saying so early keeps the program credible when the harder work starts.
The same decision can justify different methods at different times. A quoting decision might start with a pricing rule and a faster feed from the ERP, and earn a model only once the rule is followed consistently enough to show where it fails.
Data becomes useful at the point where it changes what someone does. That requires it to reach the person before the decision has to be made, to be trusted enough to act on without a second check, and to separate the options actually under consideration.
The work behind that is ordinary. Definitions have to reconcile across the ERP, the CRM, the product data system, and whatever the planning team maintains on the side. Someone has to decide which system is the source of truth for each field and who owns it. Identifiers have to match well enough for records to join without manual repair. Refresh frequency has to match decision frequency; a nightly load does not support a decision made through the day.
The people who make a decision well hold information that no system records, including which measurements drift, whose promised dates hold, and which exceptions are worth an override. We spend time with them before automating anything and write down how they decide: the rule they follow, the conditions under which they break it, and the signals they read that were never captured anywhere.
That record becomes the specification for the build. It says what the system has to reproduce, which cases have to escalate to a person, and where the current process is already correct and should be left alone. It also shows where two experienced people handle the same case differently, which is usually where both the variance and the money are.
Rules, systems, and reports accumulate faster than they get retired, and each addition was reasonable when it was made. The cost shows up later as effort the company spends coordinating with itself: reconciliations between systems that disagree about the same field, approvals that no longer change any outcome, reports maintained for people who stopped reading them, duplicate master records that every new integration has to work around.
Some of the highest-return work we do is removal. Taking out a reconciliation is usually cheaper than automating it, and it lowers the cost of everything built afterwards. It is also the hardest part of a proposal to get funded, because nothing new appears at the end of it.
We set a baseline before anything changes, using the client's existing reporting rather than instrumentation we build ourselves, and we agree with finance how the number will be calculated before there is a result to argue about. Then we make the smallest change that could move it and measure again.
When the number does not move, we say so. The cause is more often the process or the adoption than the model: the output arrives somewhere people do not look, the workflow around it never changed, or nobody was accountable for the result.
Every recommendation we make has to pass four questions:
If the answer to any of them is no, we don't recommend the work. The second question rules out more than the first. Plenty of use cases improve a decision and add a system, an interface, and a support obligation in order to do it, and the net effect on how the business runs is negative.
Tell us the process or system you are trying to improve, and we will tell you what it would take to change it.