processes produce consistency
That can be consistently good, or consistently bad. it all depends on what practices the process was modeled on. It also defines the lowest acceptable quality of output from that process. Guess what happens next? Yup, the lowest acceptable quality becomes the norm - the target. Nothing more than that is expected, or delivered as over-achieving takes longer than necessary and costs more. all for no added benefit. Frequently, a process will define the maximum time to respond - once again, that becomes the target figure too and all deliverables will tend to be delivered at or near to the target time, rather than earlier, even if they have been produced in a timely fashion (although that wouldn't happen, as there's no incentive to produce anything earlier than the deadline).
So if a process says the maximum time allowed to respond to a service call is 6 hours - then in 5 and a half hours, you can expect a call. If the process defines a response as merely an acknowledgment, then that's what you'll get: not a fix, just an email to say "^Thank you for your submission. We will get around to doing some real work in due course."
Where does all this leave the motivated, conscientious and enthusiastic workers who WANT to deliver high quality solutions (or products) in a fast and effective manner. Well, they can if they want to, buy there's no incentive or recognition for doing so - so they become demotivated, stale and cynical jobsworths who will play the system and do the minimum amount necessary to just scrape past the quality metrics. Or else they'll leave and go to forward-looking companies where their initiative and energy is harnessed, rather than dissipated, ignored or even criticised for making the other team members look bad.
Processes CAN help to produce good enough results, but all too often they don't reward the best people, crush initiative and cannot differentiate the high quality staff you would wish to keep, from the indolent types who will hide behind non-compliance in their inputs as excuses to not do any work. Essentially a process is a procedure and a procedure (as we know, since we're IT people here) is a subroutine and a subroutine is part of a program. Just look at ITIL - a software specification, if ever there was one. Programs are for computers to execute - not people. If your job is sufficiently repetitive and deskilled that it can be described in terms a computer can understand, then that's what should be doing it, not you:. Unless of course, you're happy being a drone and don't mind being laid off just as soon as it becomes cheaper for a small beige box to be wheeled in, and for you to be wheeled out.