I have seen a lot of expensive failures. I had a business partner tilt at this windmill for years. Their difficulty was their insistence that "non-technical" people be able to create reports. We built a number of solutions that people were able to learn and use to various degrees of success. Much like you, we started with parameterized canned reports.
Then we made a way to save parameter sets and associate them with different "format" templates, which essentially lets you mix and match your canned reports and publish them to other people. That was actually the most efficient thing we ever did considering it was about two weeks of development time (on top of a basic parametrized canned report system) and they used it with some success for years. It was a very simple UI, but still some users could not really build their own reports, they just couldn't work out what their criteria should be. But since anyone could build a report and share it to someone else, they could just have a co-worker make a report instead of having to go to some MIS team and stand in queue.
We kept trying to improve it though and wasted hundreds of thousands of dollars. Crystal Decisions had a pretty fancy toolkit as an add-on to their crystal reports enterprise product. This was version 9 or 10. Its long since renamed, rebranded by Business Objects but I imagine there is still a version of it. It was pretty expensive, and it gave you a complete web designer for building pretty much any report format. It also had a sample application which was more of a wizard that walked you through modifying an existing report. We'd had success with the "save & share parametrized template" idea so this appealed to us as it took it a step further. Well long story short, we didn't really deliver on it. I think the tool was ok, but what we were trying to do was just too confused and wrong to work. In the end even fewer people were able to effectively use it, and it had annoying limitations as we gradually gave up getting some features to work and our budget ran out.
All this time the business had to keep a staff of MIS developers who did a lot of their ad-hoc reporting. The best they ever got out of our stuff was a little more flexible canned reporting that best case made it faster to develop a new canned report provided there was another existing report that was somewhat similar. If you wanted to somehow integrate a new data source forget it. And mostly, thats what MIS did for them was integrate more and more data sources in a sloppy but very quick-to-market fashion.
Eventually they began heavily using Business Objects - the desktop version of the BI tool. This let you integrate local data with data that you found out about in the online metadata catalog. So you could do both real production stuff for the masses and the quants and managers could keep crunching different sets of data their research led them toward. The skill-set got even more rare, it certainly wasn't something just anyone could pick up and do. Still they were able to get a lot more people using it effectively than they could have ever afforded to hire as dedicated MIS people. MIS staff never was reduced much though, which is telling.
My own impression of this general problem is that you have got to be willing to invest significantly in skill development for the people that you imagine using this tool, and you have to accept that not all your staff is going to ever get there. And if they can't spend a couple weeks learning a BI platform, they will never be able to get the most out of any tool that you give them. Some people, for whatever reason, just never seem to get basic ideas such as outer joins. Huge classes of problem sets will never be within their reach to solve with any tool because they do not get far enough into it to understand at a conceptual level what they are really trying to ask the computer to do. That isn't to say they "can't" learn that, just that a lot of them never will.