Auf den Seiten der Kommentarübersicht werden alle öffentlichen Kommentare zur aktuellen Version der IBCS®-Standards in chronologischer Reihenfolge aufgeführt (englisch).

Rolf Hichert

Color of neutral variances

The present IBCS suggestion is to use green and red for positive variances and “medium gray” for neutral variances.

I have discussed this with Jürgen Faisst und we think that “blue” would be a better choice than “medium gray”. This is not a major issue – so why should we make this change?

In some cases it is not possible to speak of “good” or “bad” variances (e.g. reporting variances of headcount or investment figures) so we call them “neutral” variances. Nevertheless neutral variances might be as important as good or bad variances. So we think that blue would underline this better than gray. The colors blue, red and green typically are used for highlighting things – gray is not.

(This comment refers to absolute and relative variances, of course.)

Kommentar inline ansehen

I suggest to remove the sentence „Use different colors for scaling lines and scaling areas used in order to represent different scales.“

I think we should create and agree on a comprehensive semantic concept for representing different scales rather than having such an isolated rule.

Kommentar inline ansehen

I think this sentence in v1.1 is outdated:

„No rule governs the sequence of scenarios referring to the identical time period – e.g. PL 2015, FC 2015, AC 2015, but the selected sequence should be kept the same in all charts and tables.“

My understanding is that the following rule is already generally accepted and should replace the sentence in v1.2 (please comment if I’m wrong):

„The order sequence of scenarios referring to the identical time period – e.g. PL 2015, FC 2015, AC 2015 is defined by the time when the scenarios are created.“

Kommentar inline ansehen

„Therefore lines should not be used for the presentation of data series with only a few values.“ – Maybe it is worth stating a minimum quantity of values/time period or point of time? For instance, a Line Chart is recommended for a time series with at least 4 values/month (representing the data values for every week of the month) should. On the other hand, it is not recommended if the Line chart is showing 12 months and does contain 12 values only

Kommentar inline ansehen
Rolf Hichert

Hi JCA –

thank you for your comment! Of course, you are right – it should be 2017-06!
(this exhibit is not on our poster, so it probably did not get enough attention…:-)

We will change it in the next update. Thank you!

Concerning the other things which you mentioned:
Of course, these are possible and worthwhile IBCS additions. But so far we tried to suggest not too many details in the first versions of the IBCS Standards and stick to the most common problems only. We think that it would be great if we could cover 70 or 80 percent of the issues which need to be defined.

Yes, there are other topics, too, where people want to be more specific. But are these topics relevant for the majority? For many users the present version means  already „too much regulation“…

We suggest that people take whatever they can use in their environment – and add their own „amendments“ as they wish. Feel free to to so yourself…

Do you agree?

Kommentar inline ansehen


I think „figure UN 3.3-2: Abbreviations for time periods (example)“ on IBCS v. 1.1 page 120, has a mistake:
AS-IS: Month   2017-01   Jun’17   Jun
TO-BE: Month   2017-06   Jun’17   Jun

Other things:

Would it be helpful to incorporate notation for another kind of Time Series Analyses, like week-to-date (WTD), month-to-date (MTD), quarter-to-date, inception-to-date (ITD) ? Is not better to specify a single letter (y, w, m, i) instead _ or ~ ? So an example would be: qJun 2020

How would be the notation for other moving (also called rolling) analyses, for other periods different than 12 months? i.e. 6 months, 30 days, etc.



Kommentar inline ansehen

Native speakers seam to prefer the term „scale band“ instead of „scaling area“ or „scaling bar“. So I would suggest using „scale band“.

Kommentar inline ansehen

Hi Nicole,

let me first translate your question:

I did not quite understand how this is meant: „Do not use colored ares for visualization of non-area-related figures such as market shares or return sales“? Why, for example, can areas be colored for „population density“ but not for market shares?
Do you have a graphic example for area-related figures where colored areas would be good?

The answer is: The visual impression of colored areas on maps is that regions with a big area („Alaska“) have a big impact whereas regions with a small area („Singapore“) don’t. As the values of typical business figures such as market share do not correspond to the area size of the corresponding region, this gives a wrong impression.

„Population density“ on the other hand is an area-related figure („number of people per area“). This is why it would work.

Kommentar inline ansehen

Ich habe nicht ganz verstanden, wie dies gemeint ist: «Do not use colored ares für visualisation of non-area-related figures such as market shares or return sales”? Warum können für zum Beispiel „population density“, aber nicht für Marktanteile die Gebiete farblich gemacht werden?

Haben Sie ein Grafik-Beispiel für area-related Zahlen, bei denen farblich markierte Gebiete gut wären?

Kommentar inline ansehen

Hi Rolf, 

I totally agree we need more practical examples/ templates to make IBCS less theoretical therefore broaden the audience. 

The core idea of the promote using vertical lines (e.g. dashed/ light-grey) as a tool to mark beginning and end dates of a timeseries. 

(e.g. Fund performance since circulation until today)  

the advantage of this is that we have x-axis with less detailed steps (e.g. years or quarters except of days) but still have the two very important dates directly displayed in the chart. 

fiddling around with the visualization of performance charts I had to figure out that most people preferred the version with vertical lines with the start and end date of the interval even if it is a redundant information. 




Kommentar inline ansehen