This post is also available in: Español
- Administration and Maintenance
If we consider a report as the objective of a PROJECT, we can take advantage of familiar concepts of PROJECT MANAGEMENT.
If the report value is a function of the value of the decisions that will be made based on it, we now need to define what information and how we want to display it.
- Report type (see Report Types)
- The list of measures and dimensions and KPIs,
- numeric formats,
- letter fonts and sizes,
- appropriate visuals,
- the degree of interactivity (filters, buttons, bookmarks), number of pages, object hides or values,
- conditional formats
- logos, background colors
- reading devices (screen or paper size and format)
- confidentiality and legal aspects of information (GDPR)
If the report is a communication tool, you should take into account the language, habits, and culture of users.
You must not include superfluous information, nor omit the necessary
Setting the requirement accurately requires
- business knowledge
- consensus on objectives, the definition of measures and KPIs
1. Where are they?
1. In BBDD
2. In swap files
3. In Excel sheets
In any case, I must have the necessary permissions and/or credentials to access the data
2. What do they mean?
Data typically forms sets (records) that characterize values with other properties. For example, purchased units / Supplier / Product / Date
Business knowledge/operation is mandatory to understand the meaning of each record, and how it should affect our report
It is common for the numeric values of a record, or the record itself, to be contingent on what another field indicates. For example:
- valid / overridden
- sign (+ / -)
- pending / confirmed
- charged / uncharging
- posted / unposted
Is data integrity and traceability guaranteed?
Can they have been handled intentionally or casually?
Can I take responsibility for the content of the data?
What is the quality of the data?
can there be the same object with two different names?
Does the data input system give me any guarantee against possible human error?
Remember whenever the user will not be able to see the detail of the data, and will do an act of “blind” trust in what the report displays.
Reliability responsibility for the information presented cannot be delegated: the report designer must assume that it is he who gives the guarantee of the displayed data.
Note: The designer can safeguard its responsibility by exposing the assumptions on which the report is based. It shall take precautions so that a change in the structure of the data, or the structure of the undertaking, does not affect the report or that such alterations are detected and announced in the report itself.
4.Data validity date
Data evolves. Do I know the date they were extracted? Will I be working with the current dataset or one that may be obsolete?
Do I have the data at the granularity level required for my report?
Resources to solve the data stage:
In order of preference, turn to:
1. Documentation (are you sure the documentation is up-to-date, complete and true? It would be very exceptional)
2. People with experience in the company who is using this data (use your social skills, maybe you get to spend time)
3. Similar reports (plus you’ll learn a lot about your data and your company’s business to apply to your report)
4. Trial and error (I wish you luck and I hope you have the necessary time)
We can make an analogy between the design of a report, and a meal at a restaurant.
The Report requirements are our Menu preferences: we choose drinks, main dishes, and dessert.
Data is the raw material with which our order will be prepared: quality is equally important for our food as for the report.
DESIGN is the kitchen. Here, the chef (report designer) will use his knowledge to create, from the data, a report that meets the requirements.
It will be necessary to have a wide repertoire, and a lot of creativity to achieve a result not only correct, but attractive, elegant, and effective. And with a quick interactive response.
The designer will be a communicator: it will highlight the data in a way that the audience can understand and take advantage of it.
At this stage,
- we define the “back-end”
how we connect to the data,
what transformations we apply to them before they reach our report,
we define the data model, relationships between tables, hierarchies, calculated fields, the definition of measures
- we define the “front-end” that the user will see:
visuals (their distribution, format, colors, units of measure),
we implement filters and other interactivities,
we set the appropriate security/confidentiality schemes.
Of particular importance is to be able to convey to the user what the figures and graphs that they will be viewing represent, using the user language (glossary, definition page)
We will also include the date of the data, the date of preparation of the report and the period/zone/product that it covers.
The report will not be ready to be shared until you have passed the quality tests.
I mean, you will have to check that the presented data you offer is always valid, even in singular cases.
- check how our calculations respond (calculated columns, measurements) in extreme cases
- How the report responds in data reload
- As it responds to filter combinations that may result in null results, divisions by zero, date selections that include more than one period, or incomplete periods.
It will be necessary to verify the results against those that may come from other applications (ERP, accounting, other reports) until you are sure that the concepts and results are coincidental.
5. Administration and Maintenance
After validation, we will make the report publicly available.
We will probably publish it to a report server, which will give us:
- a standardized form of access (web environment, from different devices),
- security controlling access to it,
- a usage statistic (access),
- a structured catalog of reports,
- a programmable periodic data update system,
- reuse of parts of our report to authorized persons (visualizations or data model),
- export to other formats,
Companies are constantly evolving, so sooner or later, there will be a need to adapt the report to new needs. They can arise from a change in the source data structure, modifications in company processes, or new user requirements, who now want to see also something that was not requested in the original requirement. Other times, the report is prepared for an external client, who requests more information.
Modifying the requirement involves starting the report lifecycle again, taking advantage now everything already built.
For this “rebuild” to be effective, the structure of our report must be built clearly and robustly, with simple and elegant formulas that allow us to be easily review and expand the report. The documentation of the report itself, the use of appropriate names for queries, tables, fields, variable, functions are valuable for this stage.