Why Are We Doing This?
I hear often something like ‘we need to convert 100 numbers of reports within next two months, can you do it?’ Well, the answer might be Yes or No, it depends on budget, timeline, and other constraints. But more importantly, do we really need to convert all the 100 reports? We need to look at all the reports by asking, 'How many reports are really used today?’, ‘How many of the reports are really meeting today’s business requirements?’ and ‘How are those reports serving or impacting their business?’. Without asking such questions and having clear answers, all the money and effort which will be spent for the conversion related work including project preparation, project delivery, production support and maintenance will not get much return, and the worst the project might not get enough sponsor support so that the it might be forced to shut down at the middle of the project.
Energize Your Users and Get Them Excited!
As I have discussed in the previous reports conversion related posts the reports conversion itself involves a lot of manual tasks and always requires a series of testing before going to a production. Also don’t forget that the reports conversion means you are introducing a new paradigm of the reporting system to your users who might have some resistance to move to a new system just because it’s new! and they’re not psychologically comfortable with it. So we need to think about how to support both end users and developers in a form of training, documentation, user group, discussion forum, etc so that not only they will be able to transform as easy as possible and minimize a business continuity risk impact, but also we can get them energized and excited and obtain a positive support and constructive feedback from them for even a bigger and wider project.
Bring the Values to Business!
The reports conversion initiative can be a great opportunity to review the existing reports and reporting framework including its management, administration, and maintenance process. You might be able to reduce huge numbers of the reports, which of course will have big impact on the maintenance and administration cost. Also, you might be able to optimize the reporting framework to server your business better. The new BI Publisher’s RTF Template base reporting design framework allows users to use their most familiar desktop tool, MS-Word, to design the reports layout, which means you can involve the end users to design the reports layout and formatting in more collaborative form and reduce a turn around time to meet their requirements. With the BI Publisher’s RTF Template’s flexible layout/formatting and calculation support, there might be some of the requirements that couldn’t have been done before but now can be done easily. BI Publisher’s separation of data and layout layers development approach allows developers or designers to work off-line mode so that they can work anywhere and anytime.
So here is, ‘6 Keys to Deliver Successful Reports Conversion Project’!
1. Clear Objectives and Value Proposition
It’s very important to set the objectives for the reports conversion project. Why are we doing the conversion ? Is that only because Actuate support will be expired soon ? Oracle has made the decision of converting the old reporting technology to the new BI Publisher base reporting system because there are significant benefits that would server our customers better. And such benefits should be able to be translated to ‘How can those benefits serve our business better?’
Such questions lead to a set of answers which should drive the reports requirements definition and reports and reporting system design. And they can be a base guideline for all the activities during the project hence it helps leading the project team together and deliver a consistent result.
2. Requirements, Requirements, Requirements!
Even though it might take an extra time at the beginning before you start the conversion itself it would be really beneficial for both the business and IT sides to collect and review the reporting requirements based on today’s business environment, and define the requirements in a form that both the business and IT can agree upon. And this will be a baseline for the whole reports conversion exercise including the design, development, system testing, UAT(User Acceptance Testing).
Also before you start the reports conversion you want to analyze the requirements to see how to implement them with this new BI Publisher base reporting technology.
3. Gap Analysis and Solutions Development based on Best Practice
You have two different technologies, old reporting system and new reporting system. This means two different methodology to implement a same requirement. When you find the gaps between the old and new technology and develop solutions for them then they should be shared with other developers and projects so that each developer won’t need to invent the wheel every time. Also sometimes you might have possibly many ways to implement a same requirement with BI Publisher, so it’s important to analyze which options would be the best and why. These solutions can be used for many requirements and have huge impact on both maintenance and performance.
This analysis requires BI Publisher’s expert and best practice but once you have established that then the conversion process itself would be less stressful and most importantly more predictable hence easier to plan and less surprise!
3. Incremental Release, Not Big Ban
When you need to convert many reports, for example, 100 reports, it would be better to separate into small chunk of the reports sets and have a different releases schedule, maybe by department, by audience type, by reporting type, or by priority. In this way the business can recognize the value of the conversion initiative sooner and can provide valuable feedback that might have impact on the conversion strategy and reports design methodology. Again, you are going to bring a great value to your business by delivering this conversion initiative so close and continuous collaborative working relationship with the business is critical and it’s important to check if the work is aligning with the objectives and serving your business better. By focusing on a smaller user audience not just you can deliver the converted reports sooner and support them better but also you can have them on your side to promote the initiative to bigger audience for your next phases of the project. I would say three months would be typically the maximum to deliver. If it goes more than that then the business requirements would be changed and harder to manage them hence more chance to deliver something that can not serve your users.
4. Right Resource at Right Place
By this time I’m sure you’re fully aware of it, but again, the reports conversion is not just a magic that is supported by some kind of technology or methodology. It involves many phases and different types of works in order to deliver it successfully as the same way you deliver a reports development or any other projects. Therefore it requires different types of resources and you want to allocate them at a right timing and a right place and with right combination. Here is a list of the resources that would contribute the success.
- Project Manager
- Business Users/Analyst
- Functional Developers who are familiar with the backend application and the source tables such as EBS, Siebel, PSFT, JD Edward, etc.
- BI Publisher - BI Publisher has many technology but you want this BI Publisher resources who have extensive experience especially in RTF Template development
And of course, usual resource requirements for any project delivery applies such as project sponsors, system administrators/DBA, etc.
5. Well Thought and Active User Support
Again, the reports conversion will introduce a new reporting system to your users who have already accustomed to the older reporting system. The way they look at the reporting has already been established on the older system. So it will be high possibility that the users will get confused or start building a negative impact on the initiative. It’s important to understand how the users are running their reports and managing them today from their perspective. And starting from the perspective we need to identify what would be the gaps in terms of the usability and reporting procedure and build a custom training plan to address such gaps. Also, the benefits of what the new reporting system can offer often not been recognized fully by the end users or even by the developers! So it is important to translate the benefits into their daily business environment and educate the values with their language. And if you start with a smaller release with a limited number business users then they can help you to develop such training and to translate and sell the values to the business.
Also, it would help if you start hosting a user support group session at weekly or monthly where the users can throw questions or discuss requirements and solutions. What we have internally is a wiki site where we post any tips/techniques, best practice, FAQ, troubleshooting guide, which we’ve found through the development/conversion exercise to share with others. This is helpful especially when you think about scaling the development/conversion works so the more development work goes the more knowledge and experience you have as a whole team which can translate to reduce the delivery time and cost. So it’s something like ‘Center of Excellence’ as some people call it. But note that hosting such wiki site or ‘Center of Excellence’ will take a leadership effort and commitment, otherwise it will be forgotten after a few weeks, I’m sure you have seen this before! But when it works it really brings an amazing impact.
6. Project Management
Lastly it requires a sounds project management, but that is something that I don’t think I need to emphasize especially at here. Nothing is different, all the methodologies of project management will help to deliver the reports conversion project successfully as it does for any kind of projects.
No comments:
Post a Comment