Some time ago I was discussing the use of a centralised software system that had various configuration options (naturally), one of which would allow us to force employees to follow a certain process. The process was already company policy, so people should have been doing it, and it seemed natural to configure the system to make sure that was indeed happening. But one of the IT managers expressed a dislike of the idea. “Embedding a process in technology allows people to forget why the process was introduced in the first place,” he said.
This was a good point. We don’t just want people to follow rules or processes “because I said so”. There are (or should be) reasons behind those rules, and if people are convinced (rather than forced) to follow the rules then it’s more likely they will factor the reasons into other elements of their work. Or to put it another way, they will act in the spirit of the rule rather than merely to the letter of the rule.
Another reason to not embed a process or rule in technology is that, as long as the process is relatively lightweight, a technological solution will be much more difficult to adjust than a human, manual solution. Many people I know much prefer sticky notes to track their team’s work simply because it’s more flexible than any software. (Although that was before the days of enforced remote working due to Covid-19.) Often a spreadsheet is much easier than a custom database, even for fairly large volumes of work, because it’s just much easier to tweak.
Software is so-named because it can be changed. But very often a rougher, more rudimentary system allows us to do our jobs in a much more human manner.
niksilver.com 
See https://www.malotaux.eu/nrmc.php?id=fiveprocesses
Se Toyota: Tomorrow the process is already changed. That’s why they didn’t mind that the Americans took a snapshot of their processes, calling it ‘Lean’.
PDCA works on products, projects, and processes.
In 2000, at Philips I was supposed to help them with getting to CMM level 2. They had had workshops about processes, and drawn up their processes in Word documents, now expecting people to follow the processes. Of course nobody did. If someone would actually (lets be optimistic) check how to do something, it took a long time to open a Word document (“Our network is slow” …), seeing that this wasn’t the right doc, etc. It took so long that even if they would like to check it, they abandoned the attempt before finding what they wanted to find.
Then I suggested to put the processes in a website, with links, so that finding would be much faster. They said: “Can you make such a website?” I said: “I can, but I suppose I’m a bit expensive to do that.”
They insisted, so I made it a 3 week project: first week: finding out what to do and making a first attempt, for projects to check out. 2nd week: updating based on feeback. 3rd week: rounding off the work.
Of course people still didn’t follow the processes, as required by CMM. As expected, but now at least the excuse of the slow response was shown not to be the reason. This was one of the experiments we did to find out why CMM didn’t work as expected.
The next year, we introduced Eco planning. Half a year after I left, they got their CMM2 within a week: They had a process they were following, had been doing it at least half a year (CMM requirement), and only had to document it (CMM requirement), most of which was pointing to my booklets.
That’s a terrific story. Thank you, Niels.
I see a typo: Eco Planning. I suppose you know I meant Evo Planning :-)