# The innovation of the day *The same rules apply* --- People can conceptually agree that you've got to get the basics right first, and intellectually it makes sense. In practice the work takes time, and while it's taking time, board decks fly around in which someone claims that huge things have happened somewhere else. It's hard to know how much of that is marketing, for the consultants or for the businesses themselves, and harder to know what those businesses' starting points were: their underlying structures, and their ability to make the changes at all. The wrong lesson from all that is that the technology doesn't matter. The narrower one is that the forecast is usually the least reliable part of the case in front of you, and the questions you'd ask of any other investment don't stop applying because this one comes with new vocabulary. ## Margin or capital Whatever the technology, an investment has to improve what you keep from a pound of revenue, or free up capital, or both. In a business where the main cost is people's time and the asset base is light, working capital builds up mostly through delay, so real operational improvement usually comes down to three things: fewer human steps in a process, fewer errors that cause rework, and shorter backlogs and cycle times. If a case can't say which of those it moves, and by how much, it isn't a case yet. The cases that promise new revenue are growth bets, and get priced like any other growth. Some of the spend will be [[Table stakes or a lead|table stakes]] instead, made because every competitor will have the thing too, and that's a different conversation again. The incremental gains are real and shouldn't be sniffed at. A slightly better email, a document produced faster, a quicker workflow action: these are good quality-of-life improvements, and they can raise the quality bar across a business. What they don't do is automatically translate into a significant productivity improvement, or a fundamental change in revenue or cost. It's seductive to look at the cases that seem magical. The fundamental work is rethinking how the work flows through the business, and what you're actually doing. Task speed-ups don't automatically convert into money saved, either. Most teams have a backlog of should-do and could-do work that fills whatever capacity gets released, so the saving shows up as more work done rather than less money spent. That's fine, as long as the business case didn't promise the second. Be realistic about the benefit, and correspondingly vigilant about the cost of the extra tools, because that part is cash. ## Sorting the cases Two questions do most of the sorting: does the thing advise a human or act alone, and is it a single step or a chained process? | | Single step | Chained process | |---|---|---| | **Advises a human** | Assistant: helps with a task, and a person accepts or rejects each output. | Analyst: works through a problem and hands over a conclusion. A person still decides. | | **Acts alone** | Robot: a deterministic step with no judgement in it. Impact often capped, because it ends up sandwiched between human steps. | Agent: acts across a chain with no person in it. The most value, and the most risk. | The further down and to the right a case sits, the more it's worth if it works and the more it costs if it doesn't. With a person accepting or rejecting each output, errors can't build on each other unchecked. The analyst is the one to watch: its errors compound inside the chain before anyone sees the conclusion, and a polished wrong conclusion is harder to reject than a bad draft. A robot works where the environment is deterministic, with accurate data, clear rules and few exceptions. The agent is where the ambitious cases want to be. If each step is 95% accurate, one step is 95%. Five steps in a chain is 77%. Ten is 60%. Twenty-five is 28%. That assumes each step's errors are independent and nothing checks the work along the way; real chains can do better with checks built in, or worse when one error feeds the next. Either way, an agent case has to show how it survives that arithmetic before anything else about it matters. ## The org an agent sees The deeper reason the bottom row is hard in a mid-sized business is that the org an agent sees is completely different to the org a human sees. It doesn't care about reporting lines, or about the particular individuals who make a process work. It sees data schemas and workflows. Everything that makes a process work in a business this size (who to ask when a number looks wrong, which exception gets waved through and why) is invisible to it until someone has written it down. The real work needed in most mid-sized businesses is [[Bottled knowhow|codifying what they know]]. That work [[Turnarounds|gets worse before it gets better]]. Quality falls while you're fixing the data, and holding your nerve through that is part of the job while the decks keep arriving. ## What a case has to carry A clear baseline: the as-is process, the current metrics, and the problem and its impact stated in time, money or satisfaction. A clear bet: the change proposed and why it will work, how big the bet is, how it will be implemented and measured, and the risks. A clear benefit: what success looks like, the return on the investment, and the period in which it'll be realised. The baseline is the unglamorous part, and it's the one that tells you whether the rest is worth doing. Automating a process that was broken to begin with is a very old mistake, and the order of work doesn't change with the technology: processes first, then data, then systems. It's right to be cautious about the innovation of the day, but not too cautious.