Reporting Engines for Business Simulations
This explores the software module that generates reports from business data based on report formats defined in a file.
Home > Platform > Reporting Engine
Crucial to my business simulation platform is software that generates reports based on formats held in a database. As shown below, when producing a report, the engine uses format data from the database to create a template that it then populates using data from the Data and Parameter database. Then the report is displayed to screen and/or printed.
This page explores Report Generation, Types (Results Display, Decision Entry, Process Control and Other), the Reporting Database and Reports and Simulation Types).
The diagram to the below shows how the Reporting Engine generates reports. When the Simulation Manager passes a report number to the Reporting Engine, the Reporting Engine extracts the format data (report record) from the report file and uses it to create the report template. The Reporting Engine then populates the template with data from the Data File. Finally, the completed report is sent to the screen and/or to the printer.
Defining reports using format data stored in a file rather than hard coding it in software has multiple benefits:
The reports used by a business simulation are required for the results for the participants' business, reports to help the tutor answer questions and manage learning and reports used during design. The first two classes are explored in detail in Report and Simulation Types. The chart below shows how the number of reports correlates with simulation duration for a representative range of my simulations with durations from two hours to a day and a half. The short duration simulations (left) are all simulations where the participants enter their own decisions. The longer duration simulations (middle right) are ones where the tutor enters decisions (Tutor Mediated) that have a comprehensive Tutor Support System .
The chart above also illustrates the impact of having multiple versions on reports numbers. The outlier below the line are simulations were there is a single versions. The outliers above the line are complex/novel simulations or ones with multiple versions.
During the design process there is a need for reports that check logic and help with calibration. For a complex, novel simulation like my Training Challenge simulation of the 195 reports, 71 reports were used during the simulation and the remainder (124 reports) supported design. For less complex and novel simulations the number of design reports will be less. Also, for Tutor Mediated simulations some of the design reports will become part of the Tutor Support System.
As most report formats exist, all that is required to design an report is to decide it's format and what data will be used to populate it and type a single line in the Report Database - something that takes minutes. Consider how long it would take to code the number of reports shown in the chart above.
These cause a report to be displayed and/or printed. in a specific format and there are three classes of result displays - tables, graphs & charts and comment lists. Each report can have a help screen that explains the report and advises on it's implications. Each, line item in a tabular report can have an explanation of the data. Optionally, a report can have header and/or footer texts.
These present the results in a tabular form with one or more columns.
Additionally there are several format options - such as horizontal lines (to separate groups of results), displaying negatives in accounting format, comma delimiting thousands, totaling rows and displaying to the left or right, producing a variance report, displaying the rows as a percentage of the top row, displaying a blank instead of zeros.
When displaying to screen if the report is wider than or longer than the screen users can scroll the report. When scrolling to the left or right the row headings are retained. Likewise, when scrolling up or down the column headings are retained.
These present the results as graphs or charts. Besides the usual range of graphs (line, bar, stacked bar etc.) there are some special charts (dashboards, radar diagrams, histograms. traffic lights, strip charts).
These are textual comments (reflection triggers) about performance, strengths and weaknesses and provide feedback from staff, customers. bankers etc. These comments can be ambiguous stimulating reflection and discussion. Or (as to the right) comments can explain performance.
If appropriate context help can be associated with individual reports. If the Advise Button is lit (bottom left-hand corner of the screen), clicking it opens a window providing information about the report. For tabular reports and comment lists, clicking on a row, opens a window explaining the result or comment.
Headers and Footers
If appropriate result displays can have a textual header or footer.
Currently, there are nearly 50 different report types but the architecture allows the number of report types to be expanded significantly and these divide into four classes:
The Report Database also stores the decision-entry templates used by the Decision-Entry Engine.
Learn more about the Decision-Entry Engine
The report database also stores information that controls the way the business simulation progresses and how reports (and decision-entry templates) are grouped.
Learning Journey Progression
Except for very simple simulations, there will be a need for results, decisions and comments to evolve as the business simulation progresses and these progressions are controlled by report database records.
Learn more about designing the Learning Journey
Except for very simple simulations, there will be a need for several reports and decision-entry templates. These are defined by records in the database that group reports to display (Reporting Engine), data to be entered (Decision-Entry Engine) and define multiple decision-entry templates (Decision-Entry Engine). Below are the reports used bu my Financial Analysis Simulation.
These are provide other facilities such as changing the desk top's wallpaper, forcing the printer to slew a page, displaying the previous period's results, allowing a special report to be coded into the simulation.
Although for most business simulations the standard report types are sufficient, there are (complex) business simulations where the standard report types and formats are not suitable. Here the report is assembled by the simulation model and then passed to the reporting engine to be displayed and/or printed.
The Report File stores report and decision-entry templates together with other records that define report groups and reporting and decision-entry sequences. The number of records in the database varies. Simple, short or older simulations have as few as forty reports but, typically, a modern business simulation has between 100 and 200 reports. For example my Training Challenge simulation has 195 report and decision-entry templates.
Each report has a numbered record in the Reporting Database and consists of the report name (title), a link to a help record, the report type, presentation options and a parameter list.
Report Name (Title)
This is what is displayed in the report heading together with (as appropriate) team and period name.
Help Record Link
This is provides information to the on-line Help Engine to provide information about the report when this is needed.
This is provides defines the report type.
For tabular reports, there are several presentation options. For example, numbers can be presented in accounting format (with brackets around negative numbers); columns can be sorted in order; columns and rows can be suppressed; to clarify results, zero fields can be displayed as a blank, etc.
This defines report content and depends on the report type.
Each Simulation Type requires different sets of results.
These are simulations where each team competes in the same marketplaces and where decisions are entered by the tutor into a single computer.
Team Results subdivide into Preliminary Results and Full Results and provide team specific information.
Business Research consists of information to be provided to teams informing them of the economy and competitors.
Explanations allow the trainer, when necessary, to explain to teams how their results were calculated.
Tutorís Audit provides comparative highlights of team performance and so help to indicate which teams need support and which need challenging.
Team Commentaries provide additional team specific information to help assess performance, provide additional feedback and prepare for the review.
These are simulations where each team competes separately and where decisions are entered by each group by the learners into their own computer.
Period Results show the results for the period and as a review of performance to date.
Period Review shows the results for the previous period directly before decisions are made.
Ending Review is produced at the end of the simulation (after all the obligatory periods have been simulated). The ending review provides a series of reports that summarise and critique results.
Budgeting & Planning report on the results of what-if planning and budgeting (if this facility is incorporated in the simulation).
Tutorís Review is a separate group of reports that provide information to help the trainer review and critique teams. The review is accessed from the Tutor's Options.
Reconciliations are a separate group of reports to help the tutor explain the calculations. Reconciliations are accessed from the Tutor's Options.
Most recent update: 21/07/15
Hall Marketing, Studio 11, Colman's Wharf, 45 Morris Road, London E14 6PA, ENGLAND
Phone +44 (0)20 7537 2982 E-mail firstname.lastname@example.org