technology change – Allan Kelly

Is AI repeating the historic mistakes of BPR?

Back in my coding days I worked on a death-march. Six days a week and on the seventh carried a pager. The aim was to redesign the way British Railways operated. Now everyone in the UK knows how that story ended.

While politically driven it was also a case of Business Process Reengineering – BPR. It was aggressive, IT lead and became synonymous with expensive failures.

It started with some very clever (i.e. well paid) people saying “Look at the way this company operates, with new technology you could do it so much more efficiently.” The mantra was “Don’t Automate, Obliterate.” This was more than just restructuring, it was creating “Leaner and Meaner” companies.

It went beyond individual process. It meant rethinking the way the whole company operated. My railway programme was not just about selling the industry, it sought to reimagine how trains operated: companies would run trains on the same routes just a few minutes apart and compete on price.

Expensive failures

Many, probably most, BPR efforts were expensive failures. It might be easy to flowchart a process but doing so often missed vital elements. Employees tacit knowledge which made things work was overlooked. Programming a business process the way you programme a computer ignored knowledge, experience, needs and variability of people. BPR programmes used unproven, scaled and stretch technology to a degree not done before.

BPR programmes laid off vast numbers of workers before they were finished. Many of these where hired back later when the BPR effort failed, like at British Railways.

The overworked and under valued staff who weren’t laid off had to pick up the pieces. The new systems frequently didn’t work and complaining about them was not well received. (It was against this background that the British Post office and Fujitsu started the Horizon system which would see staff put in prison and commit suicide.)

Is AI repeating the mistakes of BPR?

Which makes me ask, are companies repeating the mistakes of BPR in their rush to AI?

Like BPR, AI is being driven by technologists. Rather than start with the business need it starts with technology. How is less clear, there is much hand waving. The technology is cutting edge and by definition high risk.

Rather than showing staff how AI can make their life better, staff are being forced to use AI whether it makes sense or not. Complaints are not welcomed and there are frequent examples of how AI creates problems – like at Amazon.

The attitude to workers and aggressive language is very reminiscent of BPR. Some companies claim to be laying people off because of AI and almost everyone seems to be worrying about the prospect of AI redundancies. That is not conducive to successful change.

Tacit knowledge is being ignored again

LLMs only work with explicit knowledge: that which has been written down. If it hasn’t been written into words then LLMs don’t know it. Nor does it hold any kind of philosophy or design of how things should be done. AI might write something good today but what provision is it making for changes tomorrow? Humans are still needed to guide intent.

Before anyone says: “LLM have read millions of books so they have fewer blind spots” let me point out that there is very little written down about how YOUR company actually works. Even if you have a service manual or a standard operating procedure you may well find that people use considerable ingenuity in making the standard process work or finding ways to get work done despite it.

Most AI is a solution in search of a problem.

Most people do not spend their days writing documents, neither do most people spend most of their time reading. That an LLM can write a document is another example of a technology dog walking on its hind-legs. Clever but what use?

Get away from these “party tricks” and you find AI systems – like IT systems before them – need to work with the people, processes and systems that are already there. In time AI might replace these as well but today you have the people you have, the processes you have and the legacy systems you have. Changing more increases risk.

Thus Anthropic, OpenAI and friends are not going to replace SAP, Sage, Microsoft, SalesForce, or the other corporate applications any time soon. The remaining people would need retraining, other systems would need to be integrated, formal contracts and terms and conditions might need changing. Before that, sales need to be made, which means to salesperson needs to displace salesperson. The risk of introducing a new ERP system is enough to make any CEO reach for the whiskey.

Learning from BPR failure

BPR never really went away, it was moderated and became BPM – business process management – and BPI – business process improvement . We in the IT profession learned to work in small steps, integrate feedback, let business and users drive, and to manage the change with employees rather than bludgeoning them.

AI will probably take the same route. Right now the vendors have an incentive to hype it but in time – and perhaps with some high profile failures – things will moderate. Companies will remember that AI is a technology, and technology needs to be applied to a need. In time processes and companies will change but it won’t happen overnight.

Subscribe to get Allan’s thinking in your mailbox (+ free book)

Winners and looses when AIs program

Agile / allan kelly / June 8, 2023 / ai, technology change

I feel guilty, the rest of the world has gone AI mad and I’ve said nothing about it. I’ve been hiding. Part of me feels sad and threatened, is AI going to wipe out the world I knew?

So here is my take. Since I come from a programming background, and since this is where a lot of the AI opportunities are supposed to be I’m going to talk about this. To those of you from elsewhere, let me ask: can you apply my logic to your world?

We’ve been here before, once upon a time code generators were gong to replace programmers, another time it was “programming in pictures”, another time it was 4GLs. Is this time different?

The term “AI” has been applied over the last 20 years to many systems which are little more than rules engines. These may not require programming but they do require configuration. Configuration which can be complicated – more than selecting Preferences/Edit/… and click. Instructing computer how to work, whatever the metaphor, is called programming. Anyone who says “With this tool I replace the programmers” just become a programmers themselves.

Many of those code generators, and programming by clicking systems replace one set of problems with another set.

A thought experiment

So, a thought experiment: lets suppose AI can write code as good as a human. Your programmers are replaced. What happens then?

First: do you trust what the AI writes? Or do you still need testers?

There have always been companies out there who forego testers and testing, undoubtedly many will. But in general you will want to test what the AI creates. Just because an AI says 2+2=5 does not make it right. There are already documented cases of AI exhibiting biases in things like identifying criminals.

In fact you probably need more testers for two reasons: programmers used to do some testing, while AI will not make silly syntax errors it will still make logic errors. Additionally if AIs writes more code faster than before there is simply more work in need of testing.

Second: how do you actually know what you want? – many programmers and testers spend most of their time actually understanding what customers want. Think: when you use travel planning software you may reject the first suggestion because it uses buses not trains, the second because there is too much walking, the third because you prefer connecting at one station over the other.

If the programmers are gone then testers might take on that work as part of testing (trial and error cycles). Or you might turn to Business Analysts and Product Managers. There are the specialists who understand what is wanted.

BAs and Product Managers have another role to play: post evaluation. Now it is cheaper to produce solutions there will be more solutions and someone needs to see whether they actually solve the problem you set out to solve.

In fact, there is more work to do in choosing the problems to solve in the first place. After all, building and deploying a new system is only part of the problem. What about training people to use it? What about changing the processes around it?

In fact, if we are introducing more technology and solutions faster than we are going to need more change managers analysts and consultants to advise on workflow improvements. One day your entire company may be machines working seamlessly together but until then you need to accommodate the people. Which means someone, be they BA or consultant, needs to look again at the workflow.

And if we know anything from the agile and digital movement of the last 20 years it is that changing our approach to work takes time. The technology is the easy bit. It takes years, decades even, for processes to change.

While there are still humans in the system there will still be interfaces which will need designing. Interface, UXD or experience design, is not an entirely logical processes. You need to look at how people respond. With more systems you have more interfaces and more need of interface designers.

And because adding features to your product is now so cheap you suddenly have an explosion of extra features which makes the interface more complicated and may even detract from your product value – remember how the iPod won out over other, more feature rich, competitors? So now you need you analysts and designers to limit the features you add and ensure those you do are usable.

So far we have removed programmers but increased the number of Testers, BAs, Product Manager and Designers.

In one form or another all these people will be telling the AI what to do, as I said this is call programming. So many of those new hires will be doing some form of programming. The programming paradigm has changed, perhaps its more high level, but it is still there.

If AI follows the pattern of past technology change (and why shouldn’t it?) then:

The full benefits of technology are not realised until the rest of the system, particularly processes, change to take advantage of the technology. This can take decades.

Programming isn’t going away

New technology is often billed as replacing previous technology and/or workers. It might do that in time but it also expands the market. Electricity did not eliminate candles, more candles are produced today than ever before but we don’t use them for lighting (so much.)

I don’t see AI programming bots replacing programmers in many detailed roles, perhaps ever. The ins and out of something like Modbus, and at the other extreme enterprise architecture, will make that hard. But there are domains were AI will dominate.

Finally, as we adopt new technology and processes we give rise to new innovations, we find new markets we can address and new ways of addressing existing problems. That generates work and new roles.

So I am sad to think the joys of youth spent writing ‘Writeln(“Hello world.”)’ are coming to an end, and my children will probably never experience the joy of feeling a machine perform their wishes (LDA#0, JSR OSWord, anyone?) those days are already gone.

Rationally I know AI is not something to fear (at least in the jobs context) but emotions are not always rational.

Winners and looses when AIs program Read More »