The operation understood first.
Cherrystone is a process and business-analysis practice. Most of our work never needs a model; all of it starts by understanding how the operation actually runs — and ends in a decision someone can act on.
How work actually moves.
People, systems, hand-offs and exceptions, drawn as they are — not as the procedure says. An operator should recognise the map; a board should be able to read it.
What you get: the current-state map with its waiting made visible, the hand-offs that lose work, and the three questions the map raises. Drawn in the notation your people will keep using.
When it fits: a new system is coming, a process has grown by accretion, or two teams describe the same work differently.
The case for the change — or against it.
The question behind the request, the requirements behind the change, and the cause that actually binds. Analysis that stops at a number has not finished; ours ends in a decision with its reason.
What you get: the question stated so it can be answered; requirements and acceptance criteria your builders can work from; the options with their trade-offs; a recommendation in one of nine verbs.
When it fits: before a build, before a budget, or when a decision keeps being postponed because nobody owns the analysis.
What can be measured, measured.
A rand figure is an argument; a counted unit, day or touch is a fact. We find the few numbers that describe the operation, measure the ones that can be measured, and write down what must stay true where the people who run it will keep it true.
What you get: a parameter set with the grade each number earned, the sources it came from, and the disagreements between documents, systems and people logged rather than silently fixed.
When it fits: reports disagree, a KPI is argued about more than acted on, or a procedure exists only in someone's head.
The sequence, run with your people.
Changes in the order the numbers said, run with the people who do the work, checked against the numbers they were meant to move. The order is usually the finding.
What you get: an improvement programme with its sequence and owners, the measures each change must move, and a read-back when it has.
When it fits: after a mapping or an analysis, or when a change programme has stalled because nobody can say what it was supposed to change.
When a decision needs numbers you can argue with, we bring Ipso.
When it doesn't, we don't. Ipso is the instrument for the questions where a change in one place moves something elsewhere — capacity, flow, waiting, cash — and where the answer should survive someone asking "how sure are you?"