At one point in my career, I was an instructional designer, but would make job aids for any department who requested (within reason). The department that built and maintained our point-of-sale system would sometimes ask for my help when they released a new feature. They would always ask too late (we are releasing it tonight, can you write something before the end of day? No, of course not). I would tell them to release it and they would have their job aid in 2 weeks. Why 2 weeks? Because that gave me time to visit a few locations that used the new feature. I would ask them to show me how they were using it.
When I would hand the POS team the job aid, they would always have questions like "why doesn't it follow the process we gave you?" The simple reason was that the users were skilled enough in the system that they had workarounds. They knew how to do things faster, so I used their knowledge, not the developer's knowledge.
The users found the path of least resistance.
This is an important thing to remember when you develop processes. If you make it too difficult, people will find a way to work around that. If the end result is the same, then teach people the easier way. If the end result is different, then figure out how to change the system to get the result you want. You can't change what the user does - at least not without lots of pain - but you can change to reduce the resistance.
The #1 question when looking at a process is this: can we make it easier and still get the results we want? If so, do that.