I've been using a program called BuildMaster for my personal software projects for a while now, and I have to say I am a fan. All I've really been doing with it is managing builds and releases for little apps that manage personal data for me - tracking spending, making notes, keeping time at work - but it's still been really helpful.
Previously, I would develop code up to a certain point, manually deploy it, use it for a bit, realise it had bugs, fix it a bit again, then leave it alone for a while. Repeating that process, even though I was using source control, I would grow less and less confident in the code itself and the releases I had done. What version am I running here? Could be anything. Where did it come from in source control? Can I get it back without having to fix the code I'm updating now? Not unless you figure out all the other answers first.
That's what BuildMaster does for me and my one-man, self-serve software shop. Because I'm naming releases, numbering builds and labelling them in source control, it's all tied together very nicely. Because I have set up an ad-hoc testing environment between development and production, I can do some tests before promoting a build and be confident that, should it be necessary, I can revert to a previous build or get back exactly the previous code version if I need to, without searching the source control history for what looks right.
There's a lot more the BuildMaster can do - integrating with issue tracking, automated testing, databases and so on - and some things I wish it could do natively, such as integrating with Bazaar, my personal source control system of choice, but it has been a real boon to my personal projects so far, and I intend to keep using it at least for that. If I can convince the company to use it, I think it would help at work. We have similar problems to what I had, but on a larger, more annoying scale.
Mokalus of Borg
PS - We need something at work, in any case.
PPS - Every software shop needs some kind of system, even something manual.