Perlman:Better information throughout the month on where we think our forecast and revenues are. We do this now as a monthly exercise, but sometimes you have to make fast decisions. For example, our power plants might have to decide, "Is it cheaper to run the plant, or is it cheaper to go buy the electricity somewhere else?" We are able to analyze that kind of information now. It's just that it's painful.

BPM:And it sounds like it's on a month-long schedule, as opposed to happening all the time.

Perlman:Right.

BPM:So, who initiated the project to improve the speed and quality of Constellation Energy's budgeting and management reporting? Was it you, as CIO?

Perlman:Actually, it was our users. I like our projects to be initiated by them, or at least in conjunction. This was very much a case where the users took ownership. OutlookSoft is an end-user tool. I just need to design the databases and the schemas correctly and make sure that the tool's stable and that users aren't abusing the functionality by putting everything under the sun into the system. Our users selected this tool and took ownership of designing what functions they needed in the system. But we didn't just let them off on their own. The systems people worked side by side with them and then translated that into how it would end up technically.

BPM:How did the business, finance, and IT people work together to configure the software and develop the new budgeting processes?

Perlman:Whenever we start an initiative, I make the users give me somebody that's 100 percent dedicated. You can't be part-time on these initiatives. That never works. Before this, they tried to put other BPM systems in here, but they were unsuccessful because they were just dabbled in. I would never have taken on a project like implementing OutlookSoft if there wasn't a user that was totally committed and had a very solid business need.

The way we got started with this project is the financial planning and analysis group, which is part of our CFO's office, gave us a full-time resource that helped drive the specifications. Then we worked in conjunction with OutlookSoft, who gave us a consulting resource to translate from how our departments will use the tool to our IT people. And our IT people run the gamut from functional analysts to technical people. Then this group chose a product, and implementing it was a matter of trial and error.

BPM:Why trial and error?

Perlman:I have a theory: You can either go off and do analysis and come back with this perfectly packaged analysis and make your decision, or you can iterate. I'm one to iterate, because if you don't iterate, the users never see anything. They've never gotten a chance to play with the tool, and they can't envision what they want to do.

From start to finish, it was probably less than eight months to get things up and running for the budgeting cycle. And it grew from there. We were planning just to work with the FP&A group out of corporate. We said, "We'll do something small; we'll test it out and then we'll work on adoption." Well, this thing took off like lightning. Everybody said, "Oh, there's a new tool in town. We can do our analysis." And everybody started adopting it.

BPM:It sounds like reaction from the end users was good.

Perlman:Very good. I think they were able to make life so much easier that everyone had no choice but to buy into it. The process couldn't have gotten any worse. We are very into a single source of the truth, but it was hard to have a single source of the truth while we were using spreadsheets. Now everybody can point to the same information and say, "OK, this is what we have."

The only problem I have with these kinds of tools is the users have to really start giving what they're trying to do a lot of thought. Otherwise it takes on a life of its own. We've had cases where too much was put into the tool; we should have probably done more number-crunching outside and used OutlookSoft more for analytics. You pay a performance price for that.

BPM:So, would you advise another company that was just getting started with an implementation to really focus in on what the product they're implementing is best at?

Perlman:Yeah, definitely. I'm a believer that one tool does not fit all. We're using an old version of BusinessObjects for enterprise reporting from the financial system. And we're looking to implement a tool in Oracle Financials called Daily Business Intelligence, DBI. My big thing is not to have a lot of duplication but to define where you use each tool and use it well. People can use spreadsheets when the information they're analyzing is not available to any application and is not in the database design. But I want less tools here, and I want people to become proficient in the tools. Users need to be able to stand on their own and do their own analysis.

BPM:What are the biggest obstacles to that?

Perlman:I think the hardest thing is to teach people how to understand the relationships among data so that they can then generate the reports.

BPM:How do you teach the average business user enough about data management?

Perlman:You're not going to educate everybody. In each area there's one "super user" that the IT group deals with. When we design the databases, we sit down with that super user because we have to understand how that data is going to be used. That person becomes very proficient in the data architecture.