I was interviewing a cross-functional ERP project team recently about their SAP implementation and I asked them about how they prioritized their reporting needs once their ERP was installed.
The IT project manager on the call sort of laughed and said, “If you ask them what they want, they’re going to want the world and they’re going to want every single piece of information you can possibly provide, even if they don’t look at it. It’s no hit on them. It’s just, they always think they’re going to need it to analyze.”
Notice, I used the italics to highlight something in his response. That’s an awful lot of “theys” and “thems” considering everyone on the call works for the same company.
It was an interesting, perhaps subliminal, little peak into one of the major challenges of ERP implementation: Setting reporting priorities. It really is one of the regions where the business side and the IT side can disagree. The IT project manager I mention is right: there has to be a balance between what the business users want and what they will actually need and use, especially in the early days of the implementation.
So how is that balance between the IT’s resources and the business’ reporting requirements reached?
In the recent issue of insiderProfiles magazine, Jim Newkirk, Colgate-Palmolive’s director of supp
ly chain development, says Colgate tries to create “applications” which are based on the many reports that the business requests. “When it comes to supply chain reporting, my philosophy is to have SAP deliver the applications and we’ll implement them,” he says.
But not many companies have Colgate-Palmolive’s resources. In many cases, there are some hard choices to make between “must-haves” and “nice-to-haves.”
If you’ve got some examples of reports you chose to defer or maybe some you chose to create that you never use, post a comment here. Or if you have found a way to strike a balance in your organization, all the better. I suspect there are a lot of best practices floating around in this area.