What is adoption?
A tool is adopted when it is in the building and people are using it. That is the whole of the definition, and it is a real achievement: most tools never get that far, because the barriers are people-shaped and nobody designed for them. What adoption does not tell you is whether the output is any good.
Adoption is measured by use
Licences activated, sessions, the proportion of a team that has stopped working the old way. All of these are counts of behaviour, and behaviour is what adoption work changes. Adoption is also done to people from outside, which is why it can be delivered as a programme with a start and an end.
What adoption does not tell you is whether the output is any good.
Three that passed
A department buys a new CAD package, everyone is trained, everyone uses it, and the models still carry no manufacturing intent, so every one of them is reworked downstream.
Operators log every job on a new MES because there is no other way to book time, which is a fact about the login screen rather than about the data, entered at the end of the shift from memory.
A technical function reports ninety per cent weekly active use of an AI assistant, a measure that counts sessions, while nobody has asked whether the documents it produced would survive an audit.
Attendance, not result
Adoption is attendance. Attendance is necessary and it is not the result.
Which makes it a legitimate discipline and a dangerous proxy: programmes report it because it is easy to count and it goes up. The number that answers the other question is deployment — whether the process the tool touches produces to standard, at rate, at yield, without heroics, and stays that way.
None of this is an argument against adoption. A tool nobody opens produces nothing, and getting past that is real work that mostly fails, because the barriers are people-shaped and rarely designed for. The failure is reporting adoption as though the question had been answered. If a programme can tell you how many people are using the thing and cannot tell you what the first-pass yield is on the process it touches, it has measured the half that was easy to measure.
Questions
What is adoption?
A tool is adopted when it is in the building and people are using it. That is the whole of the definition, and it is a real achievement, because most tools never get that far. Adoption is measured by use: licences activated, sessions, the proportion of a team that has stopped working the old way.
What is the difference between adoption and deployment?
Adoption is measured by use, deployment by output. A tool is adopted when people are using it; it is deployed when the process it touches produces to standard, at rate, at yield, without heroics, and stays that way. Adoption can be delivered from outside as a programme with an end date. Deployment cannot.
Why is high adoption not evidence that something is working?
Because use is a count of behaviour, not of result. A team can use a new CAD package correctly and still produce models carrying no manufacturing intent, so every one is reworked downstream. Operators can log every job on a new system because the login screen leaves no alternative. Both show as adoption.
Is adoption a useful measure at all?
Yes, and that is what makes it dangerous. It is a legitimate discipline addressing a real barrier, and it is easy to count and tends to go up, which is exactly why it gets reported in place of the harder question. Necessary, and not sufficient.