Standardisiertes Reporting: Von Rolf Hichert zu ISO 24896 und TRUECHART+
Ich erinnere mich noch genau an das Gefühl an diesem Nachmittag.
Ich saß Rolf Hichert gegenüber. Er sprach ruhig, fast akademisch, über etwas, das die meisten Menschen in unserer Branche damals für eine Frage des Geschmacks hielten: Charts, Tabellen, Farben, Layouts. Ihm ging es nicht darum, Reports schöner zu machen. Ihm ging es darum, dass sie jedes Mal dasselbe bedeuten, für jeden Leser und auch unter Zeitdruck.
„Was gleich aussieht, muss auch gleichbedeutend sein.“
Dieser Satz ist mir geblieben. Es war der Moment, in dem sich die Richtung meines beruflichen Lebens leise verändert hat.
Zu diesem Zeitpunkt war ich bereits tief in der Welt von Management Information und Planungssystemen. Ich hatte genug Board Packs und Monatsberichte gesehen, um zu wissen, dass die visuelle Sprache meist das schwächste Glied war. Unterschiedliche Teams verwendeten unterschiedliche Farben für dieselben Szenarien. Achsen wurden gekürzt, wenn es zur gewünschten Aussage passte. Abweichungen wurden so dargestellt, dass sich die Geschichte leichter erzählen ließ. Die Zahlen selbst mochten korrekt sein, aber ihre Darstellung war nicht immer verlässlich. Unter Zeitdruck wurde genau diese Unzuverlässigkeit zum Risiko.
Rolf hatte bereits Jahre damit verbracht, aus dieser Beobachtung ein schlüssiges System zu entwickeln. Die Ideen, aus denen später die International Business Communication Standards entstanden und die heute ISO 24896 zugrunde liegen, nahmen damals immer klarere Formen an. Für mich war das keine Theorie. Es war eine praktische Herausforderung, die ich nicht mehr ignorieren konnte: Wenn Reporting Entscheidungen unterstützen soll, muss die Notation genauso konsequent sein wie die Daten darunter.
Dort beginnt für mich die Geschichte von TRUECHART.
Die frühen Jahre von TRUECHART am Bodensee
Die ersten Versionen entstanden in unserer Heimatregion rund um den Bodensee. Kleines Team. Begrenztes Budget. Viele lange Abende und der hartnäckige Glaube daran, dass es funktionieren musste.
Die damaligen BI-Tools waren nicht für eine konsequente semantische Notation gemacht. Mit genügend Aufwand konnte man bestimmte visuelle Regeln erzwingen. Doch sobald die zugrunde liegende Plattform aktualisiert wurde oder eine neue Anforderung hinzukam, fiel die Konsistenz schnell auseinander.
Kunden mochten die Idee klarerer Reports oft so lange, bis sie merkten, dass sie dafür auf ihre liebsten dekorativen Charts oder die Freiheit verzichten mussten, die visuelle Geschichte etwas „zu gestalten“. Manche internen Diskussionen waren schwieriger als die Gespräche mit Kunden. „Brauchen wir wirklich ausgefüllt, umrandet und schraffiert?“ „Lohnt sich der Kampf gegen Tortendiagramme und Ampeln wirklich?“
Wir haben weitergemacht, weil sich die Alternative schlechter anfühlte: zu akzeptieren, dass Reporting eine weiche, politische Ebene auf harten Zahlen bleibt.
Ich wollte kein weiteres Consulting-Angebot, das für ein paar Wochen schöne Folien produziert und danach wieder verschwindet. Ich wollte, dass der Standard ausführbar wird. Er sollte in der Software leben, damit normale Report-Ersteller ihn anwenden können, ohne selbst zu Notationsexperten werden zu müssen.
Diese Jahre am Bodensee waren nicht glamourös. Aber sie waren das notwendige Fundament. Viele der Ideen, die bis heute im Kern der Produktfamilie stecken, entstanden dort unter realen Bedingungen: konsistente Szenariokodierung, korrekte Skalierung, klare Abweichungsdarstellungen und die Weigerung, Visualisierung als Dekoration zu behandeln.
Wie aus standardisiertem Reporting echte Software wurde
Consulting allein würde nie ausreichen. Solange das Wissen hauptsächlich in den Köpfen einiger weniger zertifizierter Experten steckte, blieb der Standard fragil. Er musste in den Code.
Deshalb entschieden wir uns, parallel zum Consulting-Geschäft eine echte Softwareentwicklung aufzubauen. Erfurt wurde dieser Ort.
Ein Produktteam vor dem täglichen Druck des Projektgeschäfts zu schützen und es gleichzeitig nah genug an den realen Reporting-Problemen zu halten, ist schwieriger, als es klingt. Wir mussten Raum für tiefe technische Arbeit schaffen, ohne die Verbindung zu den tatsächlichen Herausforderungen von Controllern, CFOs und Managementteams zu verlieren.
In Erfurt reifte die Engine. Die Chart-Logik, die Layout-Regeln, die frühen Collaboration-Funktionen und auch unser hartnäckiger Anspruch an IBCS-Konformität, selbst wenn die Entwicklung dadurch langsamer wurde, wurden Teil der DNA dessen, was später TRUECHART wurde.
Es war der Moment, in dem wir aufhörten, Consultants zu sein, die nebenbei auch Tools bauten. Wir begannen, standardisiertes Reporting als eigene Produktkategorie zu betrachten.
Singapur, Südafrika und die Partnerschaft hinter TRUECHART
2019 gründeten Bastian Lossen und ich die TRUECHART Pte. Ltd. in Singapur. Kurz darauf trafen wir eine Entscheidung, die sich rückblickend noch immer mutig anfühlt: Die langfristige Heimat unserer Softwareentwicklung sollte Südafrika werden.
2020 war kein einfaches Jahr, um ein zentrales Produktteam über Kontinente hinweg zu verlagern. Trotzdem wurde es zu einer der besten strategischen Entscheidungen, die wir getroffen haben.
Das südafrikanische Team wurde zum Hüter unserer Notation Engine. Es gab dem Produkt die Skalierung, den Fokus und die langfristige Ownership, die es brauchte. Gleichzeitig setzte der Rest der Gruppe die ebenso wichtige Arbeit fort: Implementierung, Change Management und Unternehmen dabei zu unterstützen, klarere Reporting-Praktiken tatsächlich im Alltag zu verankern.
Bastian und ich bringen unterschiedliche Stärken mit. Genau dieser Unterschied ist ein Teil des Grundes, warum das Produkt auch die langen Jahre überlebt hat, in denen große Teile des Marktes Standards noch weitgehend egal fanden. Er sieht das kommerzielle und strategische Gesamtbild mit einer Klarheit, die ich sehr schätze. Ich blieb der hartnäckige Produktmensch, der beim Grundprinzip keine Kompromisse machen wollte.
Gemeinsam haben wir weitergemacht.
Der lange Weg zu TRUECHART+
TRUECHART+ ist die Version, die ich immer bauen wollte.
Die früheren Generationen haben die schwierige, aber notwendige Arbeit geleistet, eine saubere Notation in Umgebungen zu bringen, die dafür nie entwickelt worden waren. Zuerst in Qlik, später auch in Power BI. Ergänzende Komponenten wie SLICERBAR und MENUBAR halfen dabei, die gesamte Nutzererfahrung besser zu strukturieren.
Diese Versionen haben bewiesen, dass IBCS-konformes Reporting auch im Enterprise-Umfeld praktisch funktionieren kann. Sie erhielten Zertifizierungen. Sie schufen Referenzimplementierungen. Gleichzeitig sammelten sie technische Altlasten und Reibung in der Bedienung an, die sich irgendwann nur noch durch eine vollständige Neuarchitektur lösen ließen.
Mit TRUECHART+ fühlt sich der Standard endlich nativer an. Visuelles Design, Pivoting, Light Planning und konsistente Notation leben in einer gemeinsamen Umgebung.
Das Ziel war nie, einfach immer mehr Features hinzuzufügen. Das Ziel war, den Abstand zwischen Prinzip und täglicher Praxis zu verkleinern. Die richtige visuelle Sprache soll der einfachste Weg werden und nicht zusätzlicher Aufwand.
Warum ISO 24896 standardisiertes Reporting wichtiger macht als je zuvor
Als Bastian letzten Monat seinen Artikel darüber veröffentlicht hat, warum KI einen Reporting-Standard gerade für Banken so wichtig macht, hat er etwas sehr präzise formuliert, das ich schon lange empfinde.
Solange nur Menschen Reports gelesen haben, war Inkonsistenz teuer, aber beherrschbar. Analysten lernten den lokalen visuellen Dialekt. Entscheider glichen Unterschiede mit Erfahrung aus. Missverständnisse passierten, aber es waren menschliche Missverständnisse.
In dem Moment, in dem Large Language Models und agentische Systeme dieselben Reports lesen, zusammenfassen und kommentieren, bekommt visuelle Inkonsistenz eine andere Bedeutung.
Ein KI-System, das ständig wechselnde Konventionen interpretieren muss, arbeitet auf einem weniger verlässlichen Fundament. Eine gemeinsame, formalisierte Notation, wie sie heute in ISO 24896 festgehalten ist, gibt Menschen und Maschinen ein klareres und konsistenteres Signal.
Genau deshalb hat sich der lange Weg gelohnt.
Was mit einem Gespräch über klarere Charts begann, ist heute Infrastruktur für eine Welt, in der Menschen und Algorithmen gleichermaßen schnell die richtige Aussage erkennen müssen, ohne visuellen Spin.
Ich bin stolz auf das, was unsere Teams in mehr als anderthalb Jahrzehnten aufgebaut haben. Noch spannender finde ich, was jetzt möglich wird, da der Standard keine Nischenidee mehr ist, sondern eine internationale Referenz und die Tools endlich aufholen.
Das Zeitfenster für eine vergleichsweise einfache Einführung, das Bastian beschrieben hat, ist real. Es wird nicht unbegrenzt offen bleiben. Organisationen, die die visuelle Sprache ihres Reportings als Teil ihrer Entscheidungsinfrastruktur verstehen und nicht als persönliche Geschmacksfrage, werden besser aufgestellt sein. Für ihre Mitarbeiter ebenso wie für ihre KI-Systeme.
Für diese Arbeit habe ich mich vor fünfzehn Jahren nach einem Gespräch mit Rolf Hichert entschieden.
Ich würde mich heute wieder dafür entscheiden.
Wenn Sie sich anschauen möchten, wie ISO 24896 und standardisiertes Reporting in Ihre eigene BI-Landschaft passen könnten, buchen Sie ein 30-minütiges Exploration Call mit uns. Gemeinsam schauen wir darauf, wo Sie heute stehen, welche Bereiche Ihres Reportings besonders von einer gemeinsamen Notation profitieren würden und wie ein pragmatischer Weg zu konsistentem Reporting aussehen kann.