What I found is almost the inverse of a Chesteron's Fence. Often times I see a complex process and start asking the reasoning behind such a process, everyone I talk to always has the same response: "you know I'm not sure why we do it this way, but it's important that we do it this way". At the end of the day you realize that no one really knows why they do a thing a certain way, and they are too afraid to change it.
I remember working for an insurance company in IT and we would always get a type of ticket that we were told to re-assign to another team. When I asked the obvious question of "why doesn't that team we send it to get it in the first place", I got all sorts of answers basically culminating in: "I don't know but it's the process and it's important". I eventually got someone to walk me through it and admit through their own answers that there was really no good reason to keep this process manual, as it must have been a holdover from when they had an older ticketing system. Even with all this it was impossible to change that process (at least while I was there) because the answer was always: "yeah your idea sounds good, I don't really see where we could break anything....but what if we do break something, let's just keep it as is".
I think you may have gotten the wrong impression about why I brought up Chesteron's Fence. It's not about blindly following a process; it's about understanding what risk the process is trying to mitigate.
“If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”
This means somebody needs to first understand the reasoning behind it. If, as in your example, that rationale no longer holds, getting rid of that step is perfectly inline with the principle. I would argue that if somebody truly understood the process there would be no issue with changing it.
I remember working for an insurance company in IT and we would always get a type of ticket that we were told to re-assign to another team. When I asked the obvious question of "why doesn't that team we send it to get it in the first place", I got all sorts of answers basically culminating in: "I don't know but it's the process and it's important". I eventually got someone to walk me through it and admit through their own answers that there was really no good reason to keep this process manual, as it must have been a holdover from when they had an older ticketing system. Even with all this it was impossible to change that process (at least while I was there) because the answer was always: "yeah your idea sounds good, I don't really see where we could break anything....but what if we do break something, let's just keep it as is".