My group supports the finance/accounting function. As such, they eat, sleep and breathe Excel. No matter how great a report looked, they always wanted the data in Excel. Prior to Excel::Writer, we were only able to provide CSV files - ugly, not very functional, and limited to a single worksheet. There were hundreds of CSV files that were created, so writing new, dedicated Perl programs to create Excel files was out of the question.
We wrote a Perl program that uses Excel::Writer and Text::CSV_XS to read the CSV files and create the Excel files. This works about 95% of the time without any modification to the CSV file. This was only the first step, though, and took care of all of the existing, legacy files.
The Perl program also analyzes the CSV file for, what we call, directives. These directives invoke Excel::Writer functionality. For example, '<<xl-col_format width 15 fixed 1 num_format 0%>>::Discount' will create a fixed width column that is 15 wide that displays percentages without any decimal points. 'Discount' is the data in the cell. We have implemented column/row/cell formatting directives, display directives, worksheet/workbook control directives - it's pretty fully featured.
This approach means that our staff doesn't have to learn Perl - they simply use our existing tools to create the CSV files; they only have to learn about the directives. This eases the maintenance a bit, as the staff is using tools that they are familiar with. Maintenance of these files will always be difficult, regardless of approach. We are creating Excel workbooks/worksheets cell-by-cell - this will be a labor-intensive process.
Since we've implemented this tool, we have created increasingly complex, highly formatted output - you know, the things management loves to see...
The only downside is that we need to modify the Perl program every time we want to take advantage of another Excel::Writer feature, but that's not really too big of a deal.
Mark