The Decision Company

A planner trying to promise a delivery date may have to check stock, call production, and ask sales which customer takes priority. The company has systems for all three. The planner still has to put the answer together.

That is a useful place to start a technology project. The decision is specific, the people involved are identifiable, and a wrong answer has a cost. Before choosing a tool, find out why the answer is difficult to reach.

Find a decision worth improving

Production sequences, quotes, stock orders, and maintenance priorities are decided repeatedly. Small improvements can add up, but frequency alone does not make a project worthwhile. Look at what goes wrong today, how much it costs, and whether a different process could change the result.

We ask who makes the decision, what triggers it, and what information they need. Then we follow a few actual cases, including one that went wrong. Where did someone wait? What did they check outside the system? Who could approve an exception?

A process map is useful. The work people do around the process often tells us more.

Choose a method after understanding the problem

The answer may be a rule, a report delivered earlier, a better data connection, or a change to approval authority. Some problems need a forecast, an optimizer, or a model that can interpret documents. The choice should follow what the decision requires.

Consider quoting. If the main problem is an outdated material cost, start by getting current costs into the quote. Once that works, there may be a case for a pricing model. Building the model first would leave it working from the same bad input.

Make the information usable

Useful information has to arrive before the decision is due. The person using it also needs to know what it means and whether it is current.

That takes work across systems. Customer and product identifiers need to match. Finance and operations need to agree how a measure is calculated. Someone needs authority to settle differences and responsibility for keeping the records accurate.

The refresh schedule should fit the job. A daily report may be enough for one planning task; an order commitment made throughout the day may need more frequent inventory updates. Specify that requirement before designing the connection.

Learn from the people doing it well

Experienced operators know which readings are unreliable, which supplier dates need checking, and when a normal rule should be overridden. Ask them to walk through recent cases and explain their reasoning.

Write down the conditions behind each exception. That record helps the delivery team distinguish a rule that can be automated from a case that needs judgment. Where experienced people disagree, resolve the difference with the business owner before putting either approach into software.

Look for work you can remove

Some manual work exists because two systems disagree. Fixing the definition may remove the reconciliation entirely. An approval that no longer changes an outcome may be ready to retire.

Include those possibilities in the scope. A new application brings maintenance and support costs, so compare it with a simpler change to the existing process.

Measure the result

Agree a starting measure with the business owner and finance. Use existing reporting where it is suitable, and establish how the result will be calculated before release.

After the change, check both performance and use. If the number has not improved, investigate where the process still breaks down. The output may arrive too late, the user may not trust it, or the proposed method may simply be no better.

Our four questions apply here: does the change improve an important decision, make the work easier to run, preserve useful knowledge, and leave the business able to maintain it? A promising technical result still needs a sound answer to the other three.