Phil Haack has an excellent post that strikes a nerve with me. I too often find a surprisingly large gap between controls in place for code developed by developers and controls (if any) in place for code developed by other users.

I find that, to an alarmingly large degree, steps and procedures in the Fort Knox model of software deployment are reactionary - one bad thing happened once, and as a consequence, we have to do extra work of questionable value every time we need to update software. After a while, magical properties are attributed to the sacred process and no one really remembers the reasoning behind them well enough to maintain them. It becomes ceremonial.

A process is just like a piece of software - once no one knows how to maintain it, it begins to decay.

In reality, the right solution for these problems is probably somewhere in the middle, between Fort Knox and anything goes.

Before we tackle processes for controlling change across the enterprise, we need to take a critical look at how we tackle these problems. If we have people blessing Excel documents or better blame attribution tools, will that really prevent people from making mistakes? It doesn't seem to work all that well for software, so why would it work for other problems?

Maybe the Agricultural Bank of Namibia is in hot water because they made bad business decisions. Maybe financial services firms are in hot water because they are thinly staffed and, as a consequence, poorly managed. Maybe these aren't mistakes at all, but people acting maliciously or on bad information. 

If we add process to this, I don't believe it will necessarily improve the odds that mistakes won't happen. Maybe they should do pair spreadsheeting? I don't know, but my hunch is that these aren't problems that can be fixed just by version control or QA.