The futility of process
It's soapbox day so bear with me while I take your hand and lead you through the dark, scary tunnel of logic to arrive at the conclusion that manual processes should never exist. This is going to be a long one, folks, so grab some coffee and a donut and open up your mind for this rollercoaster of rhetoric. (Note that while this post's (contrived) examples are about software development the fundamental lessons apply to any creative field.)
First of all I'd like to start by defining what I mean by "process" just so that we can start from a level playing field. A process is something a company creates in order to curb perceived or real threats to software quality which generally seeks to control the actions of software developers by making them do things they wouldn't otherwise do in the name of "control". "Control" in this case means that someone in the organization wants to feel safer because there's a process in place restricting what people are able to do and is therefore controlling their behaviour in at least a small way. A process is a set of instructions and preclusions that direct the creation of software.
Examples of things that match this definition of process are easy to find. They can be as simple as a general rule such as "never use generics" (because, presumably, someone in the past had used generics and had caused a horrible bug in the software) or as complicated as a specific, convoluted flow of steps that must be followed, documented and reviewed before bug fixes can be put into place. Both of these are sets of instructions designed to increase the perceived level of control over the creation of the software.
It's important to remember that software development is as much a creative discipline as it is scientific but since I've already covered that topic I'm not going to dwell on it any more than necessary. Suffice it to say that the more instructions and preclusions that serve to control software creation (i.e. the more process that is imposed on development) the less room there is to be creative. In environments where processes can't be circumvented or changed, it's very likely that the best solution to a problem won't be possible (such as using generics at a company where they are forbidden) or easy fixes won't be made due to the amount of towering overhead work involved (such as needing to go through weeks of reviews and/or reams of paperwork in order to make a one-line bug fix).
I want you to think more about the way I've defined processes, because I defined it that way for a particular reason: a process is a set of instructions, carried out by software developers under the constraints of preclusions. What is software? A set of instructions, carried out by hardware under the constraints of the hardware. Thus a process is very similar to the software that the process is trying to control. In fact a process is basically just software running on developers.
Software developers are humans and humans make for very poor hardware for executing sets of instructions. We have this thing called free will which makes us think for ourselves and we have this other thing called a brain which produces creativity. This brain thing also has an uncanny ability to forget important things such as instructions and even the ability to explicitly contradict preclusions in situations where the preclusions are unfavourable. It's really good at being creative and coming up with wild ideas and figuring things out and imagining how they might work and even whether they work at all. That's why the brain, in my book, is a good thing. Nevertheless, because it forgets things and doesn't like to be restrained it tends to make for a very poor software platform.
We, as brain-loving humans (as opposed to brain-loving zombies), came up with the idea of computers to follow out instructions under our constraints (and the constraints of reality itself — but that's another topic entirely) because we know that the brain shouldn't be following menial instructions. So we made hardware that isn't likely to forget anything and doesn't have free will so it's unlikely to say "Fuck off" when we tell it to do something. It saves us from having to remember rules and frees the brain's power up for the things it's so good at: free will, creativity, imagination, ingenuity, donuts.
And so I've come to Spock's second lemma: anything that can be accomplished using a manual process is better accomplished using an automated process. If it's something that can be summarized in a set of simple or complex instructions, a human shouldn't be expected to remember them. A computer is designed to do just this kind of thing without forgetting, without getting bored and without leaving to go ogle its favourite author at a book signing. And since the computer is doing all of the remembering, the software developer can focus his attention to more important tasks like figuring out how to network coffee machines without being hindered by silly rules.
This green-blooded wisdom carries an important corollary. So important, in fact, that its name must be written in bold — Spock's second corollary: anything that cannot be automated by a computer cannot be accomplished using any process. This is the futility of process. Since software development is a creative exercise, many facets of it simply cannot be automated; since they cannot be automated by a machine designed to follow instructions, how can anyone expect a human to adhere to it? Humans aren't designed to follow instructions, so they're necessarily going to be worse at it than machines.
I want you to think about what I'm saying for a moment, because I feel it is of the utmost importance. I am saying that, for any given task, the parts that can be converted into machine instructions should be converted into machine instructions and the parts that can't be shouldn't be controlled, constrained, restrained, precluded or (dare I say) quantified at all. That way the parts that are hard for human brains to deal with aren't accomplished using human brains. Moreover, the parts that are impossible to do by rote aren't constrained in any way to allow for maximum creativity (which I've already established as being vital to software development).
Our good Vulcan friend's words carry much farther than mere software development. Indeed, the lesson applies mostly to software development managers (if not management as a whole) rather than the developers themselves who, as craftsmen, favour freedom in the design and implementation of the things they create. As I stated in the second paragraph, processes are usually put into place out of a knee-jerk reaction to an unfavourable situation and are usually a set of rules instated that employees are expected to remember and follow. Often the processes are enforced only by equally squishy senior employees who also must remember the rules. If an individual from any one group forgets or misinterprets a single facet of the process, the entire process becomes useless at worst and tedious at best.
Things that can't be enforced automatically are judgement calls. Judgement calls should be made solely on the specifics of the situation requiring the call — not because someone is scared of generics and made a hard-and-fast rule about them. Many processes are easy to automate; in fact that should be the method to determine whether the process should exist at all. If you're finding a process hard to automate, think back to Spock's second corollary — maybe the process shouldn't exist at all.
Of course, discretion is still necessary, for it's entirely possible for you to automate rules like "never use generics" by writing a compiler that treats their use as errors. Just because an instruction can be automated doesn't mean it should exist. The end result here is to simplify the lives of software developers by removing the mental overhead of processes. If, for some obscure reason, all of the developers at a company agree to not using generics (maybe the target environment doesn't support them), then by all means use automation to remove them. Don't just say "never use generics" and put up big signs telling everyone not to use generics. Enforce this rule in code so that it simply cannot be done; that way you don't have to worry about it anymore.
Our pointy-eared teacher wants us to make sure we're making the most of our potential. Forcing trivial, arbitrary rules into developer brains is one extra thing that they need to worry about on top of solving your software problems. The fewer arbitrary rules they have to remember and the fewer overhead-related tasks they have to finish manually the more raw creative power they can throw at their designs. Isn't that better than a false sense of control?