From what you're describing, it is inevitable that some work will have to be done to get a good idea of what you're dealing with here.
SVN is just the repository. It is meant to store your work in a way that enables you to make mistakes without that leading to big problems. It shouldn't be used to take care of project management!
If you can get some kind of funds for a cheap server running some software development project management/ALM software, it could help you out in terms of tracking development and user queries, all linked to your repo! I'm a big fan of using ALM software. It can help you communicate and plan your development in a way that makes the human link less of a dependency. If used properly, it can really help you structure your process. (It requires some discipline)
If you have the funds to run a windows server, go TFS. It seems a good fit to what you're describing, but costs more money compared to FOSS tools. On the other hand, it is a very nicely integrated set of tools, so it'll let you manage your projects in a nicely integrated environment with a shallow learning curve. (Assuming you don't want anything special. TFS is highly configurable, but a PITA to configure if you haven't worked with the techs involved before.)
FOSS alternatives that I like are: trac, redmine or chilliproject. Except for redmine, I've only used those as a user, so I can't really tell you how easy it is to set them up.
If management won't go any further than Excel, you're out of luck. It's down to common sense in that case. I'd suggest having some kind of overview sheet and one workbook per project with one page for bug tracking, one page for release planning, and one page for documenting releases. (Just made that up now, but seems a start if you're unable to get hold of proper tools to do your job)
In terms of who's using that softare? That's anyone's guess. The only way to tell is by polling potential users, unless they have connections over the network that you could scan for with the help of a/the network administrator. As far as telling what software does, you're going to have to analyse it if no docs are available and noone is able to provide you that info. The fast but inaccurate way would be to run it in some kind of sandbox and take a look. The slow but complete way would be to review the code. (Maybe reverse engineer it with the help of an UML tool with round trip capabilties for a quick overview of the structure)
As for as the no documentation part. This looks like a good time to point out the necessity of documentation. Docs have two sides: commenting code and creating overview/usage docs.