One of my favorite stories about processes and documentation:
- Work at a hedge fund
- Every evening, the whole firm "cycles" to start the next trading day
- Step 7 of 18 fails
- I document Step 7 and then show it to a bunch of folks
- I end up having a meeting where I say: "Two things are true: 1. You all agree that Step 7 is incorrectly documented. 2. You all DISAGREE on what Step 7 should be doing"
I love this story as it highlights that JUST WRITING DOWN what's happening can be a giant leap forward in terms of getting people to agree on what the process actually IS. If you don't write it down, everyone may go on basing decisions on an incorrect understanding of the system.
A related story:
"As I was writing the documentation on our market data system, multiple people told me 'You don't need to do that, it's not that complicated'. Then they read the final document and said 'Oh, I guess it is pretty complicated' "
> Let’s rip the Band-Aid off immediately: If your underlying business process is a mess, sprinkling "AI dust" on it won’t turn it into gold. It will just speed up the rate at which you generate garbage.
In the world of Business IT, we get seduced by the shiny new toy. Right now, that toy is Artificial Intelligence. Boardrooms are buzzing with buzzwords like LLMs, agentic workflows, and generative reasoning. Executives are frantically asking, "What is our AI strategy?"
But here is the hard truth:
There is no such thing as an AI strategy.
There is only Business Process Optimization (BPO).
This is well-expressed, and almost certainly true for an overwhelming majority of companies.
A similar observation commonly comes up related to software development - "it's not tech debt, it's org debt" (or to put a different way, "trying to use a technical solution to solve a social problem").
I hear that one a lot but pretty frequently it's applied to "social problems" which were caused by technology. It seems to imply some kind of technology/society boundary which doesn't actually exist.
There was a guy who wrote a blog post in that style who was wondering how it was he'd posted hundreds of messages to people on LinkedIn and gotten no replies.
There are some people who insist on spamming out splog posts in that style, some of them think they are blogging, not splogging, and maybe they have good intentions but that style screams "SPAM!" and unfortunately people who are writing that don't understand how it comes across.
Almost every problem a modern corpo has can be solved with an appropriate head-count of appropriately trained/educated people, and that's why none of them get solved.
The processes suck because of decades of corner cutting and "fat" trimming while the executives congratulate themselves for only making the product a biiiit worse in exchange for a 0.0005% cost reduction, before then offsetting any gains by giving themselves all the money that would've gone to whatever is now dead.
Repeat this process for 30 years and you have companies like Microsoft that can barely ship anything that works anymore, and our 4 Big Websites frequently just fail to load pages for no explicable reason, Amazon goes down and takes 1/3 of the internet with it, and AI companies are now going to devour the carcass of our internet and shit it back to us in LLM waffle while charging us money for the privilege to eat it.
Honestly, I don't know if throwing people at a problem is the way to go. Doubly so given that a good chunk of the projects lately for me deal with third party vendors and those are so .. embedded that even getting basic requirements, documentation is an uphill battle ( which -- to me -- seems insane ). I have zero pull so I do what I can, notate the insanity for cya and move on.
I do agree on execs congratulating themselves afterwards though. It was obscene last year. This year it was mildly muted.
It's The Mythical Man Month idea. Programming software is a different thing than working on an assembly line, or a call center, or in retail sales. You're much better off having four programmers who are worth paying $200k a year than ten programmers who are worth paying $75k a year.
I'm going to argue that, at scale, process beats the quality of the people you're using -- and also that there are toxic cultures, around Google and C++, where very smart people get seduced into spending all their time and effort fighting complexity, battling 45 minute builds, etc.
> and also that there are toxic cultures, around Google and C++, where very smart people get seduced into spending all their time and effort fighting complexity, battling 45 minute builds, etc.
Not sure what you mean here. "Fighting" as in "seeking to prevent", or "putting up with", or what exactly? Is this supposed to be bad because it's exploitative, or because it's a poor use of the smart person's time, or what exactly?
It can both be Business Process Optimization and an AI strategy.
In fact, if an AI strategy becomes business process optimization, I'd say that AI strategy for that company is successful.
There are too many AI strategy today that isn't even business process optimization and detached from bottom line, and just being pure FOMO from the C suite. Those probably won't end well.
I feel like this is an inside view from the BPO community and the only part of AI they see is the part that affects BPO. But for most businesses AI strategy is not about AI for internal use but AI to either improve customer funnels or launch new products. Most of the companies I've talked to in the past year wanted a strategy for customer facing AI not internal AI.
The last time a company put an AI chat bot between me and actual customer service it didn’t listen to my problem and hallucinated something I didn’t say.
I have complicated feelings towards process, especially in large enterprises. In one hand, I know process is how you get good work out of average people - and that has a lot of value in big businesses because statistically, most people are going to be around average.
On the other hand, I have seen process stifle above average people or so called “rockstars”. The thing is, the bigger your reliance on process, the more you need these people to swoop in and fill in the cracks, save the day when things go horribly wrong, and otherwise be the glue that keeps things running (or perhaps oil for the machine is more apt).
I know it’s not “fair”, and certainly not without risk, but the best way I have (personally) seen it work is where the above average people get special permissions such as global admin or exception from the change management process (as examples) to remove some of the friction process brings. These people like to move fast and stay focused, and don’t like being bogged down by petty paperwork, or sitting on a bridge asking permission to do this or that. Even as a manger, I don’t blame them at all, and all things being equal so long as they are not causing problems I think the business would prefer them to operate as they do.
In light of those observations, I have been wrestling a lot with what it says about process itself. Still undecided.
The Agile Manifesto says "People over process", this can be interpreted in many ways. But ideally you follow the 80/20 rule and have clear cut processes for the most frequent cases and/or liability/law/SLA stuff you can't do without. But you should have fast escape hatches as well imo where a good engineer having admin access on a platform or deploying a hot-fix is also possible.
One thing process protects against is lazy people.
Like, we recently had an incident where someone just pasted "401 - URL" into the description and sent it off. We recently asked someone to open the incident through the correct channels. We got a service request "Fix" with the mail thread attached to it in a format we couldn't open. We get incidents "System is slow, infrastructure is problem" from random "DevOps" people.
Sadly, that is the crap you need to deal with. This is the crap that grinds away cooperative culture by pure abuse. Before a certain dysfunctional project was dumped on us as "Make it Saas", people were happy to support ad-hoc, ambitious and strange things.
We are now forced by this project to enforce procedure and if this kills great ideas and adventures, so be it. The crappy, out-of-process things cost too much time.
This doesn’t ring true to me. Having processes which rely on communication between humans using natural language can of course be either structured or unstructured. Plenty of highly functioning companies existed well before structured data was even a thing.
Structured data doesn't have be a database. It can be a checklist, a particular working layout, or even just a defined process. Many high functioning companies spent a lot of time on those kinds of things, which became a competitive advantage.
My time working in the search field for 13 years, there is always this trend:
Leaders think <buzzy-technique> is a good way to save money, but <buzzy-technique> actually is a thing that requires deeper investment to realize more returns, not a money saver.
I've seen several serveral introduction of new ERPs in companies, usually they wanted the same processes they had just with the new software, the customizing turned out be a nightmare as the consultants usually accpeted their wishes and the programmers had to bend the ERP-system accordingly, never was in budget or in time
I think there is one counter argument, LLMs are speeding up everything, including the speed of learning, which also implies that companies that might have bad processes would learn and move to good processes as well on the way.
Example, one of many things, in our SDLC process, now we have test cases and documentation which never existed before (coming from a startup).
This should go to all CEOs. They should realize that the real problem AI solves is handling of text and unstructured data. That is the core ability.
But I don't blame them. Process optimization is hard. If a new tool promises more speed, without changing the process, they are ready to pour money at that.
I recently did a pilot project where we reduced the time for a high friction IT Request process from 4 day fulfillment to about 6 business hours. By “handing text and unstructured data”, the process was able to determine user intent, identify key areas of ambiguity that would delay the request, and eliminate the ambiguity based on data we have (90%) or by asking a yes/no question to someone.
All using GCP tools integrating with a service platform, our ERP and other data sources. Total time ~3 weeks, although we cheated because we understood both the problem and process.
I suspect that could have also been accomplished without any kind of AI. Most processes are inefficient simply because nobody has taken the time to optimize them (and rightly so if they’re not used often enough to justify the time; premature optimization and all that). The act of simply deciding to optimize something, and then looking at it, usually results in significant gains just because of that, regardless of what tools were used.
In fairness, that is an extraordinary talent. The reality is that a huge amount of processes that exist have critical steps where humans have to make judgments because the information (was thought to be) not clear and structured enough for a machine.
For many processes that have just suddenly changed, somewhat subjective evaluations can be made reliably by an AI. At least as reliably as was being done before by relatively junior or outsourced staff.
Replacing low-level employees relying on a decision matrix playbook-type document with AI has a LOT of applications.
If your answer requires clustering and assembling disparate facts strewn about on the internet or company data / documents and reasoning over them, then LLMs can help that. Atleast that's what I did when I used to answer questions on stackoverflow.
How is what you linked a business process? Cancer identification is a step in a larger process, specifically the "analyze unstructured data" part that the author alludes to.
AI won't take a shoddy process (say, your process for reviewing and accepting forms from patients) and magically make it better if you don't have an idea of what "better" actually entails.
"Improving a system requires knowing what you would do if you could do exactly what you wanted to. Because if you don't know what you would do if you could do exactly what you wanted to, how on earth are you going to know what you can do under constraints?"
Cancer detection is not a process. That's a discrete step in a process.
My name isn't Russ. Russ Ackoff was a business process optimization leader from the last century -- a contemporary of Deming and the Toyota school etc.
The article mentions other steps are changing due to AI. It's a ship of Thesus result. Multiple steps are changing, some are eliminated, some are still needed, yet the overall name of the process (cancer detection) doesn't change.
- Work at a hedge fund
- Every evening, the whole firm "cycles" to start the next trading day
- Step 7 of 18 fails
- I document Step 7 and then show it to a bunch of folks
- I end up having a meeting where I say: "Two things are true: 1. You all agree that Step 7 is incorrectly documented. 2. You all DISAGREE on what Step 7 should be doing"
I love this story as it highlights that JUST WRITING DOWN what's happening can be a giant leap forward in terms of getting people to agree on what the process actually IS. If you don't write it down, everyone may go on basing decisions on an incorrect understanding of the system.
A related story:
"As I was writing the documentation on our market data system, multiple people told me 'You don't need to do that, it's not that complicated'. Then they read the final document and said 'Oh, I guess it is pretty complicated' "
reply