Why is the Reports development process in an Oracle Cloud Programme so Frustrating? Is there a better way of doing it?

100% of the projects in a heart to heart conversation will say Reporting’s one area that doesn’t work . ‘Doesn’t Work’, in Business terms by the way is something causing too many issues, or is taking too long, or doesn’t produce the desired results; so basically something that needs attention and doesn’t necessarily mean ‘Everything’s Wrong’. So lets get used to this term and take it in our stride!

The out of box configuration with some customisations is widely accepted by the Business. However report development means product development, off course you already have BIP/OTBI/OACS etc. as a tool but in most cases the complex reports will require a code that has to be written from scratch and hence I call this a product development. Limited planning, strategy, poor understanding of the requirement all add to the mix. Read on to know what these problem areas and there solutions are.

So we need a state of art solution for our operations, a solution that can integrate all our operations/departments into one single platform; and we zero in on Oracle Cloud- Excellent Choice!

The team all set, a ‘sort of ‘ project plan is defined, all components well-articulated in the plan i.e. Requirement Gathering, Design, Migration, Configuration, Development, Architecture, testing etc. However one item has either got a small space in the corner or is not invited at all to the party! And that my friends is Reporting. It’s not just you, reporting has always taken a back seat in a programme, well most of the programmes are initially (and rightly in terms of priority) are focused on the configuration/migration element of the system, you know- GL, AP, HR, Payroll etc. Sort the accounting flexfields, get the approval’s method finalised, make sure the data migration is completed successfully etc.

However this may not even be the main issue causing reporting frustration all over your programme,(one of the other) problem could be loosely written and badly understood requirements.(I have described this and other main ones at the bottom of the article)

Reporting is at the core of end users, especially in Oracle Cloud world, where a lot of day to day operations are dependent on Reporting- OTBI/BIP/PBCS/OACS etc, however incomplete or absence of planning and strategy leads to the end reporting product either

  • Not at all delivering what is required
  • Somewhat(read incorrectly) delivering what is required; and with workarounds and manual adjustments(read waste of time) somehow making it look all’s well.
  • Not being delivered at all! Or taking a long , long, long time to deliver

In my opinion the 3rd option is actually better than the 2nd as No(or prolonged) Solution is sometimes better than Half the Solution, it at least will save you from embarrassment of reporting wrong figures on a statutory report!

So the question is- is there something like a perfect reporting solution?

The answer is Yes and No. A perfect reporting product from an end user perspective could be something that gives them all there Key Columns, with correct data- and it does exist! However from programme perspective it could well be a short term solution only as it does not integrate multiple requirements into one and hence will be a headache to maintain; which well may be the case. However in this article we will be focusing on the End-User and will cover ‘Integrated Product Development’ in a future article.

So why that is the reports always take the most of the time first of all?

  • Reports don’t take most of the time, they start late in the Software Development Life Cycle.
  • Reports Development only start in full swing once the system configuration is complete- No System means No Reports(However the planning and prototyping of logical data should start earlier)
  • Building Reports- Especially BI Publisher and OACS in most of the cases is like building a new system and in lot of the cases is more complex than for example configuring Position Hierarchy.
  • Reports testing can(or should) only start once at least the System Testing of the Design-Financials/P2P/HCM etc. is complete. Late Start means Late Finish.

And now why, other than the time, why they cause so much frustration?

I am going to divide this into following main reasons, in no particular order.

  1.   Badly Understood & Loosely written requirement. Let’s call it the Bul case. Bul is the prime reason for a reporting product either being delayed or not delivering what it is supposed to deliver. This could be due to several reasons.
  2.   Wrong Methodology. A Wrong methodology could lead to defects only being identified at UAT or even worse- deployment stage. May be your programme is following Waterfall, but in some cases reports may have to follow an Agile Approach
  3.  Development Team: Skills, Inability/Will to challenge, limited understanding of the Business and Communication. The reports development should always sit outside the main Configuration/Development team and within the core Business where they can work with the Business and at the same time challenge the design/data migration. You will be surprised how many times the reporting team can find defects in Configuration or with the Data Migration- But this can only happen if the reporting team sits outside the main development/configuration team and can constructively contribute to other workstreams. Along with this the report developers need to have an all-round experience across the modules. They should not be just technical but techno-functional resources. So you need to choose your team carefully
  4.  Wrong Positioning in the Programme Project Plan: As I have also mentioned above reports have to be positioned correctly in the plan or it could lead to unnecessary testing frustrations and clashes
  5.  Badly Written or Absence of Reporting Strategy: Without understanding and without taking into account the high level requirements, limitations, restrictions, will lead to a product being delivered which for example displays Employee Personal Data in a Financial report.
  6.  Absence of a Reporting Project Plan: Needs no introduction

Want to know how best to plan your reporting project or how you could rectify your course? Wait for my next article!

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top