# New technology *Judge it like any other investment* --- When a new technology arrives, people can agree in principle that you've got to get the basics right first, and intellectually it makes sense. In practice getting the basics right takes time, and while it's taking time, board decks fly around in which someone claims the new technology has done huge things somewhere else. It's hard to know how much of that is marketing, by the consultants or by the businesses themselves. It's harder still to know where those businesses started from: how they were set up, and whether they could make the changes at all. The wrong lesson from all that is that the technology doesn't matter. The better lesson is narrower. The forecast is usually the least reliable part of any business case put in front of you, and the questions you'd ask of any other investment still apply when 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 there's little equipment or property, the cash tied up in day-to-day running 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 should be judged like any other bet on growth. Some of the spend will be [[Staying ahead|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 examples that seem magical, but 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 money saved. 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 fixed step that runs the same way every time, 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 everything is predictable: 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 how the data is laid out and the steps in each workflow. 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 [[Human bottlenecks|codifying what they know]]. That work [[Turnarounds|gets worse before it gets better]]. The quality of the work falls while you're fixing the data. Holding your nerve through that is part of the job while the board decks full of other people's success stories 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.