So, we're converting from X to Y - can you help us re-write our reports?
Often when an organization is changing from one system to another, they look to automate the process. This works fine, usually, for data, but not so well for business processes.
Typically, the new system will determine how users interact with the application and the interface - so there will be a conversion of sorts for the users in learning how to do their business using a different interface and tools. When it comes to reporting, it gets muddy. Some people get into the mindset that every report from the old system should convert into a report on the new system. And to that end - they invoke projects that seek to do just that - determine which reports are important and convert them. Now - one thing they typically do here is to attempt to minimize the demand of time on the end users/business owners. Why? Because they are very busy trying to learn the new system as it is. Remember, they have big changes in the interface they are dealing with and trying to match up how they used to do things. They are likely also attending training for the new system. So, off we go, converting all the reports to the new system. As a consulting company, we get many requests of this sort. "We're migrating from x to y and have 300 reports. How much time will it take to convert them?" Well, we can give an estimate. We can get an economy of scale if its a large enough number too. Maybe we can even get down to single-digit hours per report if we're lucky. But there is a major pitfall we have just run into.
These reports are no good!
That's right. Two major problems here. First, we didn't necessarily get an understanding of the PURPOSE of the report. Since we didn't want to bother the business owners (they were busy learning the new system) - we made lots of small assumptions over how to make the reports work with the new system. We're fairly knowledgeable, so we're probably not far off, but no one can know the real purpose of a report without asking the people who use it. Second, the business owners might have a different idea about their processes and needs as they learn the new system - making the old reports obsolete, or at least significantly different.
So, how do we get around this? It seems economical to try to mass convert reports - or to "bring over everything and we'll sort it out later". Or at least thats all we can afford to do now. What ends up happening - and we've seen this time and again - is that the reports are not used and a new project springs up gathering reporting requirements and designing a new set of reports (or reporting solution).
This is a big waste of resources!
When implementing a new system of any kind, you must analyze reporting needs from the business user's perspective as they learn the new system. Not before, not after (too late often). So, reporting needs to be integrated into the plan of learning and implementing the new system, not seen as a conversion effort. Now, those old reports are still valuable. Very valuable. They can be used to gather FUNCTIONAL requirements. From them, we can have a starting point of what they report on. This effort of analyzing the functional need of the report is one that IT staff cannot do though. Only the business owners can provide this information. And guess what? They can do that NOW, ahead of the migration to a new system. NOW, before they are inundated with training. That will give you a fighting chance at understanding their current reporting needs and the purpose of the existing reports. Then - as the implementation is moving along, we can bring up those reports and their previous purpose and use that to start the conversation of what reports are needed while using the new system. Speaking from a completely FUNCTIONAL point of view still. From that, you will build a reporting solution.
This is costly.
But, it is certainly cheaper than a project to convert all reports followed by a later project to re-analyze all reporting and build a completely new set of reports. We have seen organizations completely throw away the efforts from a mass conversion of reports after their users of the new system realized they needed a different perspective in this new system.
If you're migrating from one system to another, realize that you need the business owners input on the purpose of the reports they need and that it is far more economical (in the long run) to re-assess reporting during the implementation than it is to convert previous reports and then re-write them all again afterwards.
For additional reporting related resources click here. And for the complete library of data governance (data intelligence) related resources click here.
If you need assistance, the team of IData migration experts is available. Need help, please 
.
(image credit StockSnap_PQASJKOCU7_ReportBirdMigration_BP #1035)
