Y = f(X) Analysis: Turn a List of Suspected Causes Into a Ranked Validation Plan

Y = f(X) Analysis sits in the Analyse phase of RDMAICS. By the time you arrive here you already know the output that is failing. You measured it in the Measure phase. What you do not know yet is which inputs move it.

The tool does three things. It maps each candidate input, the X, to the output it affects, the Y. It records the direction and the strength of the relationship you observed. It records the evidence behind that observation, so a hunch never looks the same as a correlation with a p value attached.

Use it when you have more suspects than you have time to test. A team can usually name ten possible causes in twenty minutes. Validating ten causes properly takes weeks. Y = f(X) Analysis gives you an ordered list so you spend that validation effort on the inputs with the strongest recorded relationship.

Do not use it as a brainstorming sheet. Use a cause and effect diagram for that. Y = f(X) Analysis is for the step after brainstorming, when each candidate needs a named output, a direction and a line of evidence.

The worked example below is fictional. It is the sample data that loads with the tool in Ci Flow, and it is there so you can see the mechanics before you load your own numbers.

Picture an accounts payable team. Invoices take too long to process and too many of them fail the automated match. The team has three outputs they care about: cycle time in hours, first-pass match rate as a percentage, and error rate as a percentage.

They have five suspects. Invoice complexity measured by line items. Vendor data accuracy. Approver availability. The number of manual data entry steps. And the response time of the ERP system, which is the input most people in the room blamed first.

Each suspect has been looked at with some form of data. Scatter plots, correlation analysis, a time study and a process audit. That is the raw material the tool works from.

Each row in the table is one relationship. Not one input, one relationship. If a single input affects two outputs, you record it twice and treat each line separately.

For every row you fill five fields. The input variable X. The output variable Y it affects. The relationship type, which captures direction. The strength. And the evidence or data that supports the claim.

In the sample case the five rows read like this. Invoice complexity maps to cycle time, positive correlation, strong at r=0.72, backed by a scatter plot with p<0.001. Vendor data accuracy maps to first-pass match rate, positive correlation, strong at r=0.81, backed by correlation analysis with p<0.001. Approver availability maps to cycle time, positive correlation, moderate at r=0.55, backed by time study data. Manual data entry steps maps to error rate, positive correlation, strong at r=0.78, backed by a process audit with p<0.01. ERP system response time maps to cycle time, weak correlation, weak at r=0.21, and the note says it is not statistically significant.

Note the discipline in the evidence column. Three rows carry a p value. One carries a study type with no statistic. One openly records a negative finding. The tool does not reward you for hiding the weak result.

Press through to the result and the tool returns a driver review. It reports five candidate X drivers, three Y outputs mapped, three strong relationships and 5/5 drivers with evidence.

That last figure drives a readiness measure. Driver evidence readiness sits at 100 per cent because every candidate carries an X, a Y, a direction, a strength and supporting evidence. If one row were missing its evidence, readiness would fall and you would know exactly where to look.

The tool also flags that multiple Y outputs are in play and advises you to review each relationship separately. That matters here. Cycle time, match rate and error rate are three different problems. Averaging across them would be meaningless.

Below the counts sits the ranking, ordered by recorded strength. Rank 1 is vendor data accuracy to first-pass match rate at 81 per cent recorded strength. Rank 2 is manual data entry steps to error rate at 78 per cent. Rank 3 is invoice complexity to cycle time at 72 per cent. Rank 4 is approver availability to cycle time at 55 per cent. Rank 5 is ERP system response time to cycle time at 21 per cent.

An AI review is available alongside the ranking if you want the result explained in plain language.

The ranking is a sequencing device. It tells you where to point your validation work next, not what to fix.

In the sample case the decisions fall out cleanly. Vendor data accuracy and manual data entry steps earn the first two slots of validation effort. Both sit above 75 per cent recorded strength and both carry a p value. Invoice complexity follows at 72 per cent.

Approver availability at 55 per cent is a different kind of candidate. The relationship is moderate and the evidence is a time study with no statistic attached. That is a reason to gather better data, not a reason to drop it.

ERP system response time is the useful result. It was the loudest theory in the room. It lands at 21 per cent with a note that the finding is not statistically significant. Documenting that saves the team from a system upgrade business case built on nothing.

The most frequent error is reading the ranking as a cause list. An 81 per cent recorded strength means the relationship you observed was strong. It does not mean vendor data accuracy causes the match rate. A third variable can drive both.

The second error is collapsing outputs. Teams sometimes write a vague Y such as process performance. The sample data avoids this by naming cycle time in hours, first-pass match rate as a percentage and error rate as a percentage. Each Y carries its unit.

The third error is leaving the evidence column thin. A row with a strength figure and no evidence looks identical in the ranking to a row with a p value behind it. Readiness is reported as 5/5 in the sample case for a reason.

The fourth error is deleting the weak findings. Rank 5 earns its place on the list. A negative result you can point to is worth more than a theory nobody tested.

Y = f(X) Analysis will not establish causation. It records association and ranks it. The tool says so in its own closing note. To move from candidate to cause you need a designed experiment, a controlled pilot or a change where you hold other factors steady and watch the Y respond.

It will not check your statistics. If you type a strength figure, the tool records it. It cannot tell whether your sample was large enough, whether your data was stable, or whether the relationship is linear across the full operating range. The r value in the sample data came from analysis done outside the tool.

It will not find the X you failed to name. The result reports five candidate drivers because five were entered. A missing input never appears as a gap. This is why the tool follows brainstorming rather than replacing it.

It will not weigh effort, cost or feasibility. Rank 1 might be the hardest change in the business and Rank 4 might be fixable next week. The ranking is strength of recorded relationship only. You bring the judgement about what is practical.

It will not tell you the relationship holds tomorrow. A correlation measured in one period reflects that period. Process changes, seasonal volumes and new systems can all shift it. Treat the output as a snapshot, carry the top candidates into validation, and let the evidence from that work update the table.