1. If you use Notepad++ already, I'd recommend Notepad++ Integrated Perl Debugging.
2. CPAN is the Comprehensive Perl Archive Network from whence perl modules are obtained. C-SPAN is the Cable-Satellite Public Affairs Network, which allows you to watch Congress, if you really want to.
   • ActiveState perl has access to the normal cpan client... however, by default, there isn't a compatible compiler included with ActiveState (I know that recently, I saw a thread which included an ActiveState module you can download that includes a compiler for you... but I don't remember which one, so you might want to run a Super Search
   • ActiveState comes with its PPM module installer, which installs a subset of CPAN modules; the modules you want might be available thru PPM.
3. I don't have much experience with offline Excel-parsing modules, sorry.
4. Assuming I won't get too many downvotes for the heresy I'm about to utter: since you mentioned Parse::Excel, I am assuming you have access to Excel.
   • First heresy: If your license includes the VBA macros for Excel, you might want to look into just using Excel's macro-recording capability to record some of the manual tasks your coworkers perform; then, once you have that, you can tweak the resulting VBA code to become more general. Using the integrated help, I was able to learn the VBA language and the Excel object model solely from recorded macros in Excel.
   • Some orthodoxy: There's also Win32::OLE (which I think comes with ActiveState), which can be used to drive/automate Excel from perl. If you want to go down that route, Using Win32::OLE and Excel - Tips and Tricks got me to a hello-world style access to Excel thru Win32::OLE, and from there, I was able to use my knowledge of the Excel-VBA interface to go a little farther from there. MSDN Excel 2010 Developer Reference will be an invaluable reference to the Excel object model. You could even record macros in Excel VBA, then translate them to perl.
   • More heresy: a benefit of direct VBA over perl/Win32::OLE would be that to your coworkers, the macros could be run as just another part of Excel, and would probably feel more natural to them than having to run a separate perl process to edit the spreadsheet, and could be done "live" (while they are still editing the spreadsheet) instead of having to exit out of the spreadsheet just to run the automation.
   • Possible orthodoxy: I don't know whether Win32::OLE would enable access to the Excel object model even if you don't have Excel-VBA macro capability. If it does, that would increase the usefulness of perl, because you could use perl even if you don't have VBA macros. But I have no clue whether that would work (or if there even exist Excel versions without Excel-VBA, which would make it a moot benefit).

An upvote for your post, despite the heresy. ;-)

And despite the fact that I am not entirely convinced by your arguments about VBA, but I still think that it is fairly useful that you bring up these ideas to the debate.

Thank you, pryrt,for all the helpful info! Your suggestion on using VBA/Excel vs developing a separate Perl application sounds like the better choice for my non-technical colleagues. I will definitely look into VBA and see whether it can help out with the more complicated tasks I need to automate. Thanks again (greatly) for your help!

(And I do realize the difference between CPAN and CSPAN but I always make the mistake since they sound so familiar to me :P, but I appreciate the clarification)

Komodo IDE is excellent for developing Perl (and other scripting languages) assuming you really mean Komodo IDE, and not just that you have installed Active State Perl.

Assuming you have installed Active State Perl, you already have access to CPAN and CPAN modules. "ppm" provides a GUI for selecting and installing modules that Active State have packaged up for you. If you prefer to use CPAN you can do so at a command line. The Active State provided version of CPAN will install a suitable compiler the first time you run CPAN and will then function in the same way you are accustomed to on *nix.

Despite VBA being a fairly nasty language, using Excel macros written in VBA is likely to be a better fit for your colleagues - they don't then have to install Perl and possibly various Perl modules to be able to run arcane command line stuff to get magic done. For many GUI oriented people there would be too many things to learn for them to want to use your Perl tools regardless of how much work, errors and time your tools may save.

I use Textpad as my program editor for Perl dev. I think Notepad++ has similar features. I have a single button that saves all open files, runs active window and captures STDOUT to another editor screen. I've written a lot of code with this simple arrangement.

Update: I just ran ppm on my machine and there are 20,078 packages for my AS Perl version (5.20) in there ( more than the 15,000 I mentioned). That is not "everything on CPAN", but this is a non-trivial subset. Also HTML documentation is generated for every installed package. Go to START|Programs|ActiveState|documentation to launch the doc tool in your browser. This can be very helpful.

So you probably don't need to request installation or anything else from any one. Well, you most probably don't need this type of request technically, but you might still have to check the policy of your company.