Überspringen zu Hauptinhalt

SUCCESS: Das ‚E‘ steht für ‚Enable‘

Ich freue mich sehr mit diesem Beitrag Gregor Große-Bölting als Co-Autor dieses Blogs und Entwickler bei graphomate begrüßen zu können. Hier schreibt er über seine Erkenntnisse auf der SUCCESS-Kundentagung von Rolf Hichert diese Woche in Frankfurt … Danke, Gregor!


In verschiedenen Vorträgen nahmen am 17. Juni im Maritim Hotel in Frankfurt Unternehmen von der Telekom bis zur SAP die Gelegenheit wahr, sich über die Erfahrungen mit der Einführung der HICHERT®SUCCESS-Methode auszutauschen. Bei der Veranstaltung gab Rolf Hichert, Urheber der nach ihm benannten Methode, bekannt, dass am 16. Juni ein Verein Schweizer Rechts zur Förderung der International Business Communication Standards (IBCS) gegründet worden sei; die IBCS sollen mittel- bis langfristig die SUCCESS-Methode ablösen – entsprechend werde ich im Folgenden konsequent nur noch von IBCS sprechen.

Alle Vortragenden berichteten von dem Prozess, der mit der Einführung einen neuen Standards für die visuelle Kommunikation verbunden ist, wobei sich die Erfahrungen und die daraus folgenden Lehren an vielen Punkten überschnitten.

So müssen sowohl Führungskräfte, als auch die power user – also die Nutzer und Anwender, die besonders intensiv mit der Materie befasst sind – mitgenommen und eingebunden werden; niemand sollte und darf von den Änderungen überrollt werden. So wird eine hohe Akzeptanz gewährleistet. Damit einher geht die Überzeugung, dass die  IBCS zwar nicht top down eingeführt werden sollten,  aber die Unterstützung des Top-Managements zwingend erforderlich ist.

Gutes setzt sich durch

Zunächst sollte eine Kern-Nutzergruppe auf die Nutzung verpflichtet werden. Diese zeichnet sich dadurch aus, dass ihre Mitglieder sich besonders gut mit der Materie und ihren Hintergründen auskennen und (bestenfalls) an der Ausarbeitung eines internen Standards (als Abwandlung und Erweiterung der IBCS für die Zwecke des Unternehmens) beteiligt war. Bei anderen Abteilungen wird darauf vertraut, dass sie die Methode von sich aus adaptieren nach dem Motto: Gutes setzt sich durch.

(Kleine Randbemerkung: Gut ist hier durchaus im doppelten Wortsinn zu verstehen, denn (1) sind die nach IBCS erstellten Diagramme und Tabellen leicht verständlich und von hoher Qualität; (2) weisen sie gewissermaßen auch eine moralische Güte auf, die sich aus der Transparenz und Aufrichtigkeit in der visuellen Kommunikation durch den Standard ergibt.)

Es sollte zudem nicht versucht werden im ersten Wurf eine 100%-Implementierung durchzusetzen. Stattdessen ist es wichtig auf Feedback aus dem Unternehmen zu hören und schnell einen Stand des eigenen Konzepts und eine technische Realisation bereit zu stellen. Von diesem Stand aus kann weitergearbeitet und das Konzept -entwickelt werden.

Damit drehten sich die Vorträge in erster Linie um das ‚E‘ aus SUCCESS und zeigten, dass ENABLE ein wichtiger Aspekt ist, auch wenn es eine merkwürdige Stellung im sonstigen Konzept einnimmt. Wie es dazu in den Schulungsunterlagen von Rolf Hichert heißt:

ENABLE fordert eine geeignete organisatorische, personelle und systemtechnische Umsetzung des SUCCESS-Konzepts. … Bei kritischer Betrachtung müsste ENABLE außerhalb von SUCCESS diskutiert werden – aber dann wäre der Buchstabe E ohne Bedeutung…

Oberst Kaatz und SAP

Besonders beeindruckend war der Vortrag von Oberst Kaatz, der sehr lebendig und rhetorisch geschliffen über die Implementierung der IBCS im BMVg berichtete. Die Implementierung der IBCS beim BMVg läuft unter dem Akronym BASIS; besonders schön: das letzte ‚S‘ steht für: Schnickschnack vermeiden.

Warum war der Vortrag so gut?

Zum einen deswegen, weil Herr Kaatz mit konkreten Lösungen für reale Probleme aufwarten konnte: Wie leistet man intern Überzeugungsarbeit für das neue Konzept? – In dem man das Thema emotionalisiert, für es eintritt und seine Begeisterung zeigt; niemand setzt sich ernsthaft für Ampeln und Torten-Diagramme ein, so dass man auf der emotionalen Ebene schnell gewinnt. Wie überzeugt man die Führungskräfte? – In dem man nicht bereits bestehende Änderungen verteufelt, sondern „sanft“ Verbesserungsmöglichkeiten aufzeigt; in dem man der Führungskraft zu dem das Gefühl gibt, sie wäre – gewissermaßen wie in der Mäeutik – selbst auf diese Idee gekommen. Wie bringt man den Adressaten dazu den Geschäftsbericht auch tatsächlich zu lesen? – In dem man, wie in einem Roman, einen Spannungsbogen hält, der auch über 180 Seiten trockenen Reporting trägt. Wie macht man die Controller glücklich? – In dem man ihnen einen Service bietet, der die Arbeit erleichtert und das Ergebnis ihrer Arbeit verbessert.

Zum anderen, weil der Vortrag – man muss es einfach so sagen – fesselnd und sprachlich brillant war.
Natürlich war es auch gut zu hören, dass von Oberst  Kaatz auch unsere Entwicklung für SAP BusinessObjects Design Studio explizit hervor gehoben wurde.

Ein weiteres Highlight war der Vortrag der SAP. Die SAP ist ein Weltkonzern und ein entsprechender Aufwand wird mit dem internen Berichtswesen betrieben. Die SAP ist außerdem ein IT-Konzern, was zu dem nahe liegendem Ergebnis führt, dass man den zuständigen Mitarbeiten eine Software-Implementierung der IBCS zur Verfügung stellt.

Neben einem Excel-Wizard, der die Standard-konforme Erstellung von Diagrammen ermöglicht, hat die SAP einen mächtigen Assistenten (auf Grundlage von Crystal Reports) zur Generierung von Reports erstellt: Der Sachbearbeiter nimmt zunächst Konfigurationen zu Berichtstyp, Datenquellen, etc. vor, die Einstellungen werden als veränderbare Vorgabe gespeichert, so dass sie für den nächsten Berichtszeitraum wieder zur Verfügung stehen. Das System generiert automatisch alle notwendigen Tabellen und Diagramme; diese müssen im Anschluss noch um Kommentare ergänzt werden. Es gibt zu dem die Möglichkeit weitere Seiten in das Gesamtwerk einzufügen. Nachdem alle notwendigen Daten, Diagramme und Erläuterungen vorhanden sind, sammelt das System alle Seiten und fügt sie zu einem einzigen PDF zusammen. Der resultierende Zeitgewinn ist enorm.

Aber auch die SAP favorisiert den Einsatz unseres graphomate addons zur Abbildung von HICHERT®SUCCESS mit SAP BusinessObjects Design Studio: Man forderte uns augenzwinkernd auf, doch bitte mit der graphomate HTML5-Entwicklung für Design Studio „in die Pötte“ zu kommen. 😉

Die Rolle der IT

Ein letzter Punkt, der für mich spannend war und der auch mich als Entwickler direkt betrifft, war die Diskussion, welche Stellung die IT in der Ausarbeitung eines internen Standards und bei der Implementierung von IBCS in einem Unternehmen einnehmen sollte.

Die einhellige Meinung dazu war, dass die IT solange wie möglich aus den Entscheidungsprozessen herausgehalten werden sollte. Die Gründe dafür leuchten ein: Zum einen neigen Entwickler dazu sich in Details zu verrennen; zum anderen hat man – sobald ein Entwickler am Tisch sitzt – eine Diskussion zur Machbarkeit. Die Machbarkeit aber sollte keine Rolle spielen, vielmehr sollte zunächst ein geschlossenes Konzept vorhanden sein. Dieses Konzept kann dann umgesetzt und falls notwendig hinsichtlich der Machbarkeit einzelner Punkte nachjustiert werden.

Fazit

Es war beeindruckend, welcher Aufwand durch die Firmen getrieben wird und getrieben werden muss, um von einer Art der Darstellung von Diagrammen auf eine andere umzustellen. Es scheint sich bei diesen Dingen um ein hoch emotionales Thema zu handeln. Fast alle Referenten berichteten, welche Diskussionen allein um die Farben geführt wurden. Insofern stellt das Ausarbeiten eines unternehmensweiten Standards immer nur die eine Seite der Medaille, dessen Einführung, die andere Seite dar.

Für mich war es die erste Veranstaltung im Hichert-Universum. Das bedeutete zunächst einmal: zuhören und lernen. Und schauen, wie die Anwender dessen, was ich programmiere, ticken. Die Lehre die ich für mich gezogen habe ist, dass die Details, die uns in der Entwicklung manchmal Kopfzerbrechen bereiten, für den Endanwender Marginalien sind (was natürlich nicht bedeuten soll, dass sie nicht trotzdem wichtig sind). Derjenige, der die Software benutzt, braucht zunächst einmal ein zuverlässiges Tool, das er intuitiv bedienen und das den Bedürfnissen des Unternehmens entsprechend konfiguriert werden kann.

Bald mehr von mir, Gregor

Über den Autor: Gregor Große-Bölting ist seit Mai als Entwickler bei der graphomate GmbH beschäftigt und aktuell mit der Gestaltung des User Interfaces für das Design Studio-Addon betraut. Daneben studiert er an der Christian-Albrechts-Universität zu Kiel Philosophie und Informatik mit dem Ziel den Abschluss als Master of Arts zu erlangen.

_

_

ccbync
Dieser Beitrag bzw. Inhalt ist unter einer Creative Commons-Lizenz lizenziert.

Dieser Beitrag hat einen Kommentar
  1. Hallo Gregor

    Toller Blogbeitrag – gibt einen guten Einblick in die Tagung, an welcher ich leider nicht teilnehmen konnte. Speziell gefallen hat mir, dass offenbar das Thema Enable nun doch noch etwas mehr Gewicht bekommt in der Hichert-Community. Gleichzeitig hat mich aber die folgende Aussage irritiert:

    „Die einhellige Meinung dazu war, dass die IT solange wie möglich aus den Entscheidungsprozessen herausgehalten werden sollte. Die Gründe dafür leuchten ein: Zum einen neigen Entwickler dazu sich in Details zu verrennen; zum anderen hat man – sobald ein Entwickler am Tisch sitzt – eine Diskussion zur Machbarkeit. Die Machbarkeit aber sollte keine Rolle spielen, vielmehr sollte zunächst ein geschlossenes Konzept vorhanden sein. Dieses Konzept kann dann umgesetzt und falls notwendig hinsichtlich der Machbarkeit einzelner Punkte nachjustiert werden.“

    Nun ja, immerhin wiederspiegelt dies genau meine Wahrnehmung, wie Hichert+Partner das Thema bisher getrieben haben – ohne Rücksicht auf Verluste wenn’s zur Umsetzung kommt. Als Wirtschaftsinformatiker (und ja, ich geb’s ja zu, zu grossen Teilen immer noch ein Techi) bin ich aber stets beiden Seiten verpflichtet: Dem Fachbereich und der umsetzenden IT. Ich kann nicht einem Kunden ein Konzept verkaufen (und mag es noch so einheitlich und durchdacht sein), wenn es sich anschliessend nicht umsetzen lässt. Denn was wäre dann der Sinn davon? Aus meiner Sicht gilt es hier nun zwei drei Dinge zu unterscheiden, auf welche ich kurz eingehen möchte:

    1. In der heutigen IT-Welt werden mehr und mehr Standard-Softwarelösungen eingesetzt. D.h., Anforderungen des Fachbereichs können nicht wie früher 1:1 programmiert werden, sondern es gibt stets die Leitplanken der eingesetzten Standardlösungen. Nur noch die ganz grossen (wie die erwähnte SAP) leisten sich bei Bedarf die in der Erstellung und Unterhalt teureren Individualsoftwareentwicklungen. Die vielzitierte Excel-Alternative hält häufig den gestiegenen Anforderungen an Compliance, Audits etc. nicht stand und sollte gerade deswegen nicht favorisiert werden.

    2. In SUCCESS steht das U für UNIFY. Wenn immer ich mit Rolf Hichert zu tun hatte, war mein Eindruck, dass UNIFY nicht nur einzelne Lösungsbereiche „vereinheitlichen“ soll, sondern im Idealfall für alle Auswertungen in einer Unternehmung gelten soll (inkl. der oft geringgeschätzten „Statistiken“ – oder für BI-Leute einfach Reports oder Analytics). Die nächste Stufe mit IBCS und einem globalen Standard ist ja nicht weniger ambitioniert.

    3. Aus Punkt 1 und 2 folgt, dass eine Unternehmung selten nur eine Standardsoftware verwendet, sondern mehrere. Daraus leite ich ab, dass das hehere Ziel von UNIFY sein muss, über kurz oder lang die Notation in all diesen Auswertungsapplikationen zu vereinheitlichen. Auch wenn es vielleicht nicht für alle Anwendungen auf’s mal machbar ist, das Ziel muss sein, einen unternehmensweiten Standard zu etablieren.

    4. Es gibt aus meiner Sicht den wichtigen Unterschied zwischen SUCCESS und HI-NOTATION. Wobei der Begriff SUCCESS *Rules* irreführend ist. SUCCESS sind höchstens allgemein gehaltene Guidelines. Die Regeln als solches werden im Notationskonzept der HI-NOTATION plus minus exakt festgehalten (wobei immer noch zu wenig präzise um darauf basierend eine technische Umsetzung vornehmen zu können, aber wem erzähl ich das ;-). Gleichzeitig ist auch nur die HI-NOTATION problematisch in der Umsetzung. Denn Rolf Hichert hat bei ihrer Entwicklung keine Rücksicht auf die Umsetzbarkeit genommen (was je nach Perspektive und Zielsetzung durchaus gerechtfertigt ist!). Umgekehrt kann man SUCCESS als solches nicht einfach umsetzen, sondern muss auf Basis dieser Guidelines ein eigenes Notationskonzept erstellen und dieses lässt sich dann – vielleicht – umsetzen.

    5. Möchte man konzernweit die HI-NOTATION etablieren, so ergibt sich daraus was ich als das „Hichert Paradox“ formuliert habe: UNIFY ist die Ausgangslage für HI-NOTATION mit dem Ziel, die Notation von Geschäftskennzahlen im Unternehmen zu vereinheitlichen. HI-NOTATION ist heute höchstens auf Basis von Nischenlösungen abbildbar (Excel, graphomate in Xcelsius, Design Studio; mittels Add-Ons in QlikView etc.), weil die Umsetzung mit handelsüblicher Software heute (noch?) nicht möglich ist. Das führt unweigerlich dazu, dass das eigentliche Ziel von UNIFY nicht mehr erfüllbar ist. Und damit verhindert die HI-NOTATION für was sie eigentlich gut sein soll.

    6. Wie kann man das Hichert-Paradox überwinden? Auf lange Sicht wünsche ich Firmen wie euch, graphomate, dass ihr es schafft mit eurer hervorragenden Software nicht nur in Nischenprodukten wie Xcelsius und Design Studio integriert zu sein, sondern auch in den Rest der SAP Analytics Suite. Oder sogar bei anderen BI-Herstellern. Wer weiss. Auf kurze Sicht jedoch gibt es nur eine Option, wenn man die Notation wirklich vereinheitlichen will: Man muss mit der Software auskommen, die man hat zum jetzigen Tag (und nicht was in drei vier Jahren vielleicht dann mal kommt) Und das bedeutet, man muss bei SUCCESS beginnen und ein darauf basierend ein Notationskonzept erarbeiten, dass eben durchaus die Umsetzbarkeit in Betracht zieht! Denn sonst endet man womöglich im gleichen Problem wie die HI-NOTATION.

    7. Daraus folgt: Vielleicht soll nicht der reine Techi / Entwickler bei der Konzepterstellung mit am Tisch sitzen. Aber es braucht unbedingt Personen mit an Bord, welche von Beginn weg die Rahmenbedingungen der einzusetzenden Standardsoftware-Lösungen kennen und im Bezug auf die Notation einschätzen können, was im Ansatz geht und was nicht. Gleichzeitig müssen sich die Fachvertreter (und die „reinen“ Notationsberater) von Beginn weg im Klaren sein, dass ein Konzept, das sich nicht umsetzen lässt, am Schluss weder UNIFY noch ENABLE entspricht und damit nicht SUCCESS-konform genannt werden kann.

    Herzliche Grüsse
    Raphael Branger

Kommentare sind geschlossen.

An den Anfang scrollen