We're in a similar situation, Joerg, although we have a bit more background with SQL. If you look at our site you'll see that we have implemented only a small part of the OpenACS functionality with some relatively minor changes. As you have heard so far, turning on default functions (once your system is installed) often requires no programming at all. So for example, a complete non-programmer (like me) can create a new bboard and set its characteristics from a web interface. Other changes require minimal futzing with .ini files and the like, which shouldn't be too intimidating for you if you've had to keep, say, a Win95 machine running for more than an hour at a time. 😉
However, be warned that even seemingly minor changes can turn out to be major headaches. Part of this is inherent in programming, but much of it is because ACS (and therefore OpenACS) is not well abstracted in a lot of areas. The most frustrating part for us has been not being able to anticipate what's going to be hard to change. Again, the problem is not that tcl or SQL is hard; the problem seems to be mainly with the way ACS is wired together.
Fortunately, OpenACS has a truly fantastic, supportive, smart community associated with it. In some ways, the community has been more valuable than the software itself for us, because they have made it much easier for us to solve our problems quickly.
