Ziele sollten als unerreichbar gesetzt werden, aber als erreichbar wahrgenommen werden

Ingo Diedrich hat mit seinem Post Ziele sind nicht zum Erreichen da eine Steilvorlage für mich zum Weiterdenken meines Posts Projekte stehen in der Regel für Mittelmaß geschlagen, die ich in diesem Post gerne verarbeiten möchte.

In meinem oben aufgeführten Post Projekte stehen in der Regel für Mittelmaß habe ich bereits den Systemarchetyp der erodierenden Ziele als Muster verwendet, um den Übergang von der Ergebnis- hin zu einer Prozessorientierung und die einhergehende Abwärtsspirale der Zielauslobung darzulegen. Diese Argumentationskette möchte ich nun weiter ausführen und stoße dabei auf zwei scheinbar gegensätzliche Thesen, die ich folgend miteinander versöhnen möchte.

  1. Ziele müssen so gesetzt sein, dass sie grundsätzlich erreichbar sind.
  2. Ziele müssen so gesetzt sein, dass sie grundsätzlich nicht erreichbar sind.

Die erste These wird wahrscheinlich Jeder sofort unterscheiben. Durch ausgelobte Ziele erzeugen Teams ihre Daseinsberechtigung, quasi ihre Identität. Es wird definiert, wofür das Team steht und wofür es nicht steht. Durch Ziele wird eine Basis geschaffen, die es einem Team überhaupt erlaubt als Team zu agieren. Aus dieser Sicht gesehen ist es dann ja auch logisch, dass die Ziele dann auch als erreichbar angesehen werden müssen.

Die zweite These wird spannender und auf den ersten Blick für die meisten Leser nicht gleich hinnehmbar. Was meine ich mit dieser These?

Zielerreichung

Ziele sollten stets Mittel zum Zweck, niemals zum Selbstzweck mutieren, was sie zu oft tun. Das möchte ich an Projekten in einem Unternehmen verdeutlichen. Die Argumente könnte man aber auch relativ einfach auf einige andere Bereiche des Lebens ausdehnen.

In einem Unternehmen wird der Bedarf an der Generierung eines Mehrwertes in einem bestimmten Bereich nachgedacht (Launchen eines neuen Produktes, Erschließen einer neuen Verkaufsregion etc.) Dafür wird dann ein Projekt aufgesetzt. Zu diesem Zeitpunkt ist das Projekt samt seiner Ziele noch Mittel zum Zweck. Der Zweck ist die Generierung des Mehrwertes für das Unternehmen.

Dann wird das Projekt geplant, mit Ressourcen “bestückt” etc. Es wird über den Scope und den einhergehenden Risiken gesprochen. In diesen Diskussionen wird dann häufig der Scope des Projektes reduziert, um Risiken zu mitigieren. Das Projekt an sich rückt immer mehr in den Mittelpunkt und der eigentliche Sinn des Projektes, die Generierung des Mehrwertes für das Unternehmen, in den Hintergrund, bis er ganz verschwunden ist.

Innerhalb der Durchführung des Projektes ist man dann auch noch dem Systemarchetyp der erodierenden Ziele aufgesessen. Hat man erst mal begonnen, Ziele herabzustufen, kommt man aus dieser Spirale nicht mehr heraus. Man reduziert sie fortwährend. Damit entfernt man sich mit den zu erreichen wollenden Ziele des Projektes immer von den initial gesetzten Zielen, die den Mehrwert für das Unternehmen reflektieren.

Wenn also Ziele so definiert werden, dass sie erreichbar sind, wird das gesamte Potential eines Teams nicht annähernd ausgeschöpft, denn man wird die Priorität bei der Definition der Ziele auf die Erreichbarkeit dieser setzen. Logisch, man wird ja an die Erreichung dieser Ziele gemessen. Man befindet sich dann im Mittelmaß.

Wie könnte nun eine Versöhnung aussehen und welche Voraussetzungen sind notwendig, um dieser Versöhnung Leben einzuhauchen?

Ich persönlich gehe stets mit dem folgenden Mindset an ein Projekt im beruflichen Bereich oder auch an Vorhaben im privaten Sektor.

  1. Ich setze das zu erreichende Ziel so hoch wie möglich und mache mir im ersten Moment keine Gedanken darüber, ob ich es erreichen kann. Ich lasse mich nur vom zu erreichenden Mehrwert leiten.
  2. Ich will dieses Ziel erreichen, unbedingt. Ich habe dabei aber stets im Blick, ob das Ziel bei der Abarbeitung stets relevant bleibt. Im Laufe der Zeit mag es ja sein, dass das Ziel gar nicht mehr wert ist es erreichen zu wollen.
  3. Ich lande da, wo ich lande.

Was habe ich damit erreicht? Im Sinne der Sache auf jeden Fall mehr, als wenn ich gleich am Anfang des Vorhabens das Ziel nach Grad der Erreichbarkeit gesetzt hätte.

Was muss aber gegeben sein, damit die oben beschriebene Vorgehensweise auch umgesetzt werden kann?

Die Erreichung der Ziele darf nicht mehr als Gradmesser für die Einstufung und Bewertung der Leistungen der Mitarbeiter herangezogen werden. Denn ist das der Fall, werden alle Mitarbeiter ihre ganze Energie darin legen, Ziele zu erreichen und dafür unter Umständen auch Ziele herunter schrauben, unabhängig davon, ob diese dann noch einen Mehrwert darstellen oder nicht.

Ein Projekt muss Risiken implizieren. Ein Projekt ist stets etwas Neuartiges und hat dieses keine Risiken ist es nicht wert es überhaupt zu starten. Dieser Gedankengang muss in der Definition der Ziele Berücksichtigung finden.

In diesem Sinne sollte man auch beachten, dass in der Regel die Projekte, in denen ganz offen eine Zielverfehlung thematisiert wird, einen höheren Mehrwert schaffen, als die, in denen am Ende des Projektes Zielerreichung propagiert wird. Natürlich darf das aber nicht bedeuten, dass man auf Teufel komm raus versuchen sollte, Ziele nicht erreichen zu wollen. Dann wäre man nämlich auf dem entgegengesetzten Pol zu “Ziele unbedingt erreichen wollen” angekommen.

Und wir streben ja eine Versöhnung an.

1 Star2 Stars3 Stars4 Stars5 Stars (4 Bewertung(en), Durchschnitt: 4.00 von 5)
Loading...
Posted in Management und Leadership | Tagged , | 3 Comments

Interview auf der nächsten Online Mitglieder Konferenz der GVDK e.V.

Die Gesellschaft für Vernetztes Denken und Komplexitätsmanagement e.V. wird am Samstag, den 16. März 2013 von 19 bis 21 Uhr ihre nächste Online Mitglieder Konferenz durchführen. Die Agenda zu diesem Event finden Sie hier. Zur Anmeldung gelangen Sie über diesen Link.

Buch_Von einem der auszog

Ich freue mich sehr an diesem Event aktiv teilnehmen zu dürfen. Die Veranstalter haben um ein Interview mit mir gebeten, in welchem wir meine Motivation zum Schreiben dieses Blogs und meines neusten Buches Von einem der auszog die Wirtschaft zu verstehen thematisieren werden.

Seien Sie doch gerne dabei.

1 Star2 Stars3 Stars4 Stars5 Stars (1 Bewertung(en), Durchschnitt: 5.00 von 5)
Loading...
Posted in Komplexität | Tagged , | Leave a comment

Data Scientists – die Robin Hoods im BI Dschungel?

Im Post Kennzahlen in Unternehmen – eine Versöhnung ist angebracht habe ich den Drang der Menschen thematisiert, in Gegensätzen zu denken. Dies holt uns grundsätzlich beim Lösen von Problemen immer wieder ein.

In dem oben angesprochenen Post habe ich den Vergleich zwischen Problemlösen und dem Bewegen auf einem Band gewagt. Die Lösung zu einem Problem suchen wir stets auf dem entgegengesetzten Pol des Bandes. Dieses Denkmuster wurde uns quasi durch das Anwenden der zweiwertigen Aristotelischen Logik eingebläut. Entweder etwas ist gut oder böse. Entweder etwas ist schön oder hässlich.

Dieses Entweder-Oder-Denkmuster möchte ich jetzt wiederum auf die neuesten Strömungen im Business Intelligence reflektieren und die Auswirkungen aufzeigen.

Es geht um die Rolle des Data Scientists.

Lassen Sie uns ein paar Jahre zurückschauen.

Ich erinnere mich noch genau an BI Projekte, die ich bis zum Jahre 2010 durchgeführt habe. Jedem war klar, dass die Rolle des Business Analysten in einem BI Projekt besetzt sein muss. Business Analysten sollten unter anderem die funktionalen und nichtfunktionalen Anforderungen an eine zu implementierende BI Lösung zusammen mit dem Kunden definieren. An die Rolle des Business Analysten war also schon immer ein hoher Anspruch an Wissen und Erfahrung in dem jeweiligen Businesskontext gesetzt. Im Bereich des Datenhandlings war in der Regel kein allzu hoher Anspruch an die Business Analysten definiert, was letztendlich dazu führte, dass Business Analysten nicht datenaffin waren.

Dann kam der Datenhype. Modewörter wie Big Data

  1. Web-Daten: Clickstreamdaten, E-Commerce Logs, Onlinespiele, Onlinewerbung, Soziale Netzwerke (z.B. Facebook, Twitter)
  2. Semi-strukturierte Daten, z.B. XML, E-Mail, EDI
  3. Unstrukturierter Content, z.B. Freitext in Produktbewertungen in E-Shops
  4. Sensordaten, z.B. Temperatur, Licht, Vibration, Geodaten, Durchfluss, Druck, etc.
  5. Branchenspezifische strukturierte Transaktionsdaten, z.B. Telekommunikationsdaten

bestimmten und bestimmen die Hochglanzbroschüren dutzender Beratungsunternehmen. Logisch. Man hat auf der einen Seite erkannt, dass BI Projekte nicht sonderlich erfolgreich waren. Auf der anderen Seite konnte man sich der steigenden Datenflut, die die Welt durchzieht, nicht mehr verwehren. Also waren die Daten der Hebel für den Erfolg. Man musste sie nur besser nutzen. Klar.

In diesem Zuge wurde dann auch eine neue Rolle für BI Projekte geboren, der Data Scientist. Bei der Auslobung dieser neuen Rolle ist sehr schön das von mir angesprochene Entweder-Oder-Denkmuster zu erkennen. Man sucht jetzt datenaffine Menschen. Sie müssen Wissen in statistische Verfahren und den entsprechenden Tools haben. Sie müssen in der Lage sein, Muster in Daten zu erkennen, die dann wiederum Entscheidungen unterstützen sollen.

Es werden nun also vorrangig Naturwissenschaftler (Statistiker, Physiker, …) gesucht, die die Rolle des Data Scientists ausfüllen sollen. Nach Kenntnissen in dem jeweiligen Businesskontext wird nicht mehr gefragt. Warum auch? Es geht doch um Daten und die Handhabung dieser.

Ist das nicht der absolute Wahnsinn in welchen Gegensätzen wir denken?

Um aus den Daten, die unverhohlen in Massen vorliegen und tagtäglich neu generiert werden, Information und damit Erkenntnisse für das jeweilige Business zu gewinnen ist BEIDES von Nöten.

Erfahrung und Wissen im Umgang mit Daten sowie Erfahrung und Wissen bzgl. aktueller Trends in dem jeweiligen Geschäftssegment, in dem das Unternehmen agiert.

Statt ENTWEDER-ODER ist also SOWOHL-ALS-AUCH gefragt.

Ich möchte es an dieser Stelle noch einmal ausdrücklich betonen. Ich bin mir sicher, dass wir heute nicht ansatzweise das Potential heben, welches die Daten für Entscheidungssituationen im Business besitzen. Wir sind uns dessen wahrscheinlich noch nicht einmal richtig bewusst. Ich glaube fest daran, dass durch Mustererkennung in Daten, Erkenntnisse für den jeweiligen Businesskontext erschlossen werden können, an die man heute noch gar nicht denkt. Das passiert aber nicht in dem „blind“, also ohne Ideen welche Muster das sein könnten, in den Daten herum stöbert. Diesen Vorgang vergleiche ich gerne mit dem Suchen nach „etwas“ in einem großen Sandhaufen, ohne zu wissen, was dieses „etwas“ ist.

Wenn man nicht weiß wonach man sucht, wird man es auch nicht finden.

Data Scientists sollten mit ganz kleinen Hypothesen starten. Das sind ganz konkrete Fragestellungen aus dem Business, die sie mittels Daten lösen wollen. Im ersten Schritt muss man also sehr bewusst vorgehen. Mit der Zeit, so bin ich der Meinung, entwickelt der Data Scientist ein gewisses Gefühl für den Zusammenhang von Daten und Businesspotentiale. Das bedeutet, er muss sich dann nicht mehr konkrete Fragen vornehmen, sondern kann dann Surfen und sich treiben lassen. Dann geht es nicht mehr um das Suchen, sondern um das Finden.

Was könnten solche kleinen Hypothesen sein? Beispielsweise könnte man vermuten, dass eine bestimmte Kundengruppe zu einer bestimmten Tageszeit besonders geneigt ist, bestimmte Produkte zu kaufen. Für diese Kundengruppe gestaltet man dann zu diesen Tageszeiten den E-Shop mit diesen entsprechenden Personalisierungen aus. Man könnte dann noch das aktuelle Wetter hinzuziehen oder auch bestimmte aktuelle Strömungen und Meldungen aus der Politik. Man könnte beispielsweise auch Produktwolken aus den Verkaufsdaten bilden, in denen Produktaffinitäten (z.B. Kunden, die Toshiba Fernseher kaufen tendieren in der Zweitmarke eher zu Siemens als zu Philips) definierter Kundengruppen abgebildet sind. An dieser Stelle sind der Phantasie keine Grenzen gesetzt.

Es fehlt heute nicht an der Technologie, um Daten für das Business zu handhaben. Es fehlt an Ideen, wo der Hebel in den Daten liegen könnte. Um diesen zu finden benötigen wir eine Versöhnung zwischen den Business Analysten und den Data Scientists.

1 Star2 Stars3 Stars4 Stars5 Stars (1 Bewertung(en), Durchschnitt: 5.00 von 5)
Loading...
Posted in Management und Leadership | Tagged , , | Leave a comment

System Dynamics durch Anwendungsbeispiele begreifbar machen

Um Teams oder eine Gruppe von Menschen überhaupt handlungsfähig im Sinne von Problemlösungsprozessen aufzusetzen, ist es unerlässlich, dass die Menschen dieser Gruppe die gleiche Sprache sprechen. Damit meine ich nicht nur unsere Sprachen im herkömmlichen Sinne, sprich das gemeinsame Wissen um die Bedeutung des Wortes “Tisch”.

Ich meine damit auch, und dieser Fakt wird oft unterschätzt, das Schaffen einer gemeinsamen Basis, um die subjektiven Wahrnehmungen, die jeder Mensch von seiner Umwelt erzeugt, den Mitmenschen kommunizierbar zu machen. Da geht es also für jeden einzelnen Menschen darum, seine inneren Modelle (Mindsets), die er durch seine eigens gemachten Erfahrungen aufgebaut hat und die Basis seines subjektiven Urteilens und Handelns sind, anderen Menschen verstehbar zu machen. Das dies nicht zu 100% umsetzbar ist oder anders gesagt, wir niemals darüber urteilen können, ob die 100% erreicht sind, habe ich in verschiedenen Posts meines Blogs ausgeführt (Einem Menschen begreifbar zu machen, wie eine Zitrone schmeckt, der noch niemals eine Zitrone gekostet hat, ist unmöglich). Das sollte uns aber nun nicht dazu verleiten es dem Vogel Strauß gleich zu tun und den Kopf in den Sand zu stecken.

Eine Möglichkeit, diese Basis zu schaffen ist System Dynamics.

Ähnlich zu anderen Methoden, lebt auch System Dynamics von guten Anwendungsbeispielen, welche die Möglichkeiten und den Nutzen der Methode demonstrieren. Die Internationale System Dynamics Society hat damit begonnen, eine Sammlung lehrreicher Anwendungsbeispiele zu erstellen.

Auf dieser Plattform können Sie bereits eingereichte Anwendungsbeispiele, beispielsweise aus den Bereichen Bildung, Gesundheit oder auch Ökonomie und Finanzwesen, erkunden. Ein Blick in diese Beispiele lohnt aus meiner Sicht auf jeden Fall. Vielleicht haben Sie selbst einen interessanten Fall, den Sie mit der Gemeinschaft teilen können. Informationen darüber, wie sich ein solcher Fall einreichen lässt, finden sich hier.

1 Star2 Stars3 Stars4 Stars5 Stars (Keine Bewertungen bislang. Geben Sie doch die erste ab.)
Loading...
Posted in Modellierung | Tagged , | Leave a comment

Kennzahlen in Unternehmen – eine Versöhnung ist angebracht

Der Artikel Ein Unternehmen ohne Ampeln – Werte als Kraftfeld von Entscheidungen der Plattform Initiative Wirtschaftsdemokratie hat mich motiviert, meine Gedanken und Ideen zum Thema Kennzahlen in Unternehmen zu konkretisieren.

Grundsätzlich lasse ich mich beim Analysieren und Lösen von Problemen immer mehr vom Versöhnungsgedanken leiten. Gotthard Günther, den ich bereits des Öfteren in meinem Blog erwähnt habe, hat mich mit seinem Zitat

Wenn ein Problem wieder und wieder auftaucht und keine Lösung gefunden werden kann, dann sollte man nicht danach fragen, was die Vertreter gegensätzlicher Standpunkte voneinander unterscheidet, sondern was sie gemeinsam haben. Das ist der Punkt, wo die Quelle des Missverständnisses liegen muss.

in diese Richtung geleitet.

Ich stelle mir beim Lösen von Problemen stets ein Band vor. Das Problem befindet sich auf der einen Seite des Bandes. Die Lösung aber nicht auf der anderen Seite, sondern häufig in der Mitte zwischen beiden Polen. Häufig wird aber genau so vorgegangen, dass beim Problemlösen eine komplette Kehrtwende eingeschlagen wird und Alles verteufelt wird, was mit dem Problem in Verbindung gesetzt wird.

Beim Problemlösen sollte man also weder

das Kind mit dem Bade ausschütten

noch

sollte man Angst vor Wasser haben, wenn man sich waschen möchte.

Versöhnung bedeutet also weg vom ENTWEDER-ODER hin zum SOWOHL-ALS-AUCH Denken. Das möchte ich an dem Beispiel der Unternehmensführung andeuten und mich dabei auf den im ersten Satz gelinkten Artikel (im Folgenden als Referenzartikel bezeichnet) beziehen.

Ergebnis- vs. Prozessorientierung

Wie schafft man Orientierung in einem Unternehmen im Sinne eines gemeinsam gewollten Ganzen? Bei der Beschäftigung mit dieser Frage fokussiert man sich zunächst auf einen Zielzustand: Was soll erreicht werden? Man argumentiert ergebnisorientiert. Wurde hier Einigung erzielt, wird ausgearbeitet, wie dieser Zustand (diese Zustände) erreicht werden soll(en). In dieser Phase geht man dann in die Prozessorientierung über. Die Orientierung erreicht ihre Reife im Sinne eines Prozessmanagements. Es werden Rollen, Aktivitäten, Verantwortlichkeiten etc. definiert und diese gesteuert.

Hat man einen bestimmten und gewünschten Zielzustand in der Zukunft im Fokus (Ergebnisorientierung), sind Aktivitäten, diesen zu erreichen, Mittel zum Zweck. Geht man in die Phase der Prozessorientierung über, werden diese Aktivitäten ganz schnell zum Selbstzweck. Diese Pfadabhängigkeit kann man dann auch nicht mehr so einfach verlassen, da Rollen und Verantwortlichkeiten und damit Existenzen von Menschen daran gekoppelt sind.

Hier möchte ich das Beispiel der Verkehrsregeln aus dem Referenzartikel anführen. Wenn wir unseren Kindern das Überqueren einer Straße mit Ampel erlernen lassen möchten, geben wir ihnen ein Ziel mit auf dem Weg: “Unbeschadet auf der anderen Straßenseite ankommen.” Natürlich ist die Ampel ein Referenzobjekt, an dem sich die Kinder ausrichten. Bei ROT auf jeden Fall stehenbleiben. Bei GRÜN kann man gehen, allerdings abhängig vom Straßenverkehr. Wir würden nicht ansatzweise auf die Idee kommen unseren Kindern ein Prozessmodell mit allen möglichen Parametern

  • Art der Fahrzeuge
  • Beschaffenheit der Straße
  • Wetterverhältnisse
  • Tageszeit

erlernen zu lassen. Warum? Weil wir wissen, dass wir nicht im Stande sind, alle Eventualitäten durchzudeklinieren. Es können Umstände auftreten, die wir nicht vorhersehen können. Das wissen wir. Vor Überraschungen sind wir nicht gefeit.

Ist es in Unternehmen denn anders? Natürlich nicht. Nur warum handeln wir im beruflichen Umfeld anders? Warum negieren wir im beruflichen Umfeld Überraschungen? Prozessmanagement und Planung trägt beispielsweise zum Nicht-Anerkennen-Wollen von Überraschungen bei.

Mit jeder Aktivität, die in einem Unternehmen ausgeführt wird, sollte stets die Frage einhergehen, welchen Mehrwert im Sinne des gewünschten gemeinsam gewollten Zielzustandes diese Aktivität stiftet. Die Aktivitäten, für die eine Beantwortung nicht gegeben werden kann oder wo man sich damit schwer tut, sind Streichkandidaten.

Ich steuere beispielsweise meine Projekte, für die ich als Projektleiter verantwortlich bin, grundsätzlich nur über Ergebnisse und Teilergebnisse, niemals über Aktivitäten. Die Verantwortlichen der einzelnen Ergebnisse machen sich natürlich dediziert Gedanken, wie sie die Ergebnisse und Teilergebnisse am besten erreichen können. Sie sind auf Aktivitäten- und damit auf Prozessebene unterwegs.

Es muss also stets ein gesunder Mix zwischen Ergebnis- und Prozessorientierung bestehen. Ohne Prozessorientierung gibt es erst gar kein Ergebnis und ohne Ergebnisorientierung verkommen Prozesse zum Selbstzweck. Versöhnung.

Ergebnisorientierung ist nicht gleich Ergebnisorientierung

Das folgende Zitat des Referenzartikels

Kennzahlen, Ziele, Anweisungen, Prozessvorgaben, Checklisten, sie wirken alle wie Scheuklappen. Ich spreche mich nicht grundsätzlich gegen diese Instrumente aus. Als Mittel der Selbstorganisation können sie nützlich sein. Als Mittel der Fremdsteuerung sind sie jedoch fahrlässig. Denn sie ignorieren die Dynamik unserer Welt. Sie nehmen an, die Welt sei perfekt.

sollte man am besten in Schriftgröße 50 und fett unterstrichen aufführen. Allerdings möchte ich dieses Zitat folgend differenzierter betrachten, da in diesen Sätzen Ergebnis- und Prozessorientierung vermengt wird. Das wir bei Anweisungen, Prozessvorgaben, Checklisten etc. (Prozessorientierung) Nebel erzeugen, der uns bei der Wahrnehmung der Vorkommnisse in der Umwelt hinderlich ist, habe ich oben aufgezeigt.

Im Folgenden möchte ich mich auf Kennzahlen (Ergebnisorientierung) stürzen und aufzeigen, dass auch hier der Nebel sehr leicht aufziehen kann.

Was ist eigentlich der Sinn und Zweck von Kennzahlen?

Kennzahlen reduzieren Komplexität, wie in dem Referenzartikel auch angemerkt. Genauer gesagt reduzieren sie die Eigenkomplexität eines Unternehmens. Mit dieser Reduktion schaffen sie eine Basis für ein gemeinsames Handeln. Man könnte auch sagen, dass mit Hilfe der Kennzahlen ein Abbild des Marktes erzeugt wird, nach dem ein Unternehmen sich ausrichtet und agiert. Kennzahlen reduzieren aber nicht direkt die Fremdkomplexität des Marktes (Details: Dialog zu den Themen Komplexität, Entropie, (Nicht)Wissen und ihre Auswirkungen auf Ethik und Entscheidungen). Denn, wird innerhalb eines Unternehmens streng nach bestimmten Kennzahlen gesteuert, hat das einen Einfluss auf die Mitarbeiter des Unternehmens. Sie schränken dadurch den Optionsraum der Handlungen der Mitarbeiter ein und reduzieren so die Eigenkomplexität des Unternehmens. Allerdings hat diese Handlungsleitung keinen direkten Einfluss auf den Markt (Kunden, Lieferanten, Wettbewerber). Der Markt hört nicht auf diese Kennzahlen, auch wenn wir es gerne hätten. Die Fremdkomplexität bleibt also erst einmal konstant und damit wird die Schere zwischen Eigen- und Fremdkomplexität größer.

Allerdings muss man bei der Komplexitätsreduktion bedenken, dass nicht alles messbar ist, was wir gerne messen würden. Hier wird der Brückenschlag von der toten zur lebendigen Wissenschaft zu kurz gefasst. In dem wir etwas messbar machen, reduzieren wir die Komplexität des zu Messenden, und hier meine ich dann wieder die Eigenkomplexität des Unternehmens, nicht die des Marktes, denn dem Markt ist relativ egal, wie das Abbild von ihm im Unternehmen ausschaut. Das kann dann dazu führen, dass die Eigenkomplexität so gering ist, dass sie nicht mehr im Einklang zur Fremdkomplexität steht und damit Unternehmen nicht mehr lebensfähig sind (Gesetz von Ashby).

Auf der einen Seite sollte also nicht mit aller Wucht ALLES, was gesteuert werden soll, in Kennzahlen abgebildet werden, besonders die Themen nicht, die nicht messbar sind und das sind in der Regel die Themen, die massiv von Menschen abhängen (Man könnte nun natürlich die Diskussion aufmachen, ob nicht Alles in Unternehmen von Menschen abhängt. Ja tut es.). Diese werden in der Literatur oft als softe Faktoren hervorgehoben. Zum Anderen werden aber Kennzahlen genutzt um Handlungsfähigkeit herzustellen, da sie Basis für Verständigung herstellen. Auch hier ist also eine Versöhnung angesagt.

Kennzahlen sind also grundsätzlich notwendig. Allerdings dürfen sie nicht zum Selbstzweck mutieren. In einem Unternehmen sollte nicht agiert werden, um einen gewissen Wert für eine Kennzahl zu erreichen, ähnlich wie Kinder in der Schule nicht lernen sollten, um eine gute Zensur zu erreichen.

In gewisser Weise kann man Kennzahlen mit unserer Sprache und unserer Schrift vergleichen. Beim Sprechen und beim Schreiben wird auch eine Projektion in ein Abbild der Umwelt durchgeführt, welches als Verständigungsbasis dient. Alleine schon das Sprechen und das Schreiben bedeutet Komplexitätsreduktion. Nur weil im Rahmen von Kommunikation Missverständnisse aufkommen, würden wir auch nicht auf die Idee kommen, Sprache und Schrift abzuschaffen.

Diese Notwendigkeit einer Versöhnung lässt mich auch stets ganz oft zu dem Satz hinreißen, dass wir niemals Komplexität beherrschen können, allenfalls können wir sie handhaben.

1 Star2 Stars3 Stars4 Stars5 Stars (2 Bewertung(en), Durchschnitt: 5.00 von 5)
Loading...
Posted in Komplexität, Management und Leadership | Tagged , , | 2 Comments

Wie wäre es denn mal mit Zu-Ende-Denken?

Vor einigen Tagen bin ich durch einen Weggefährten meiner Reise des Verstehens, Martin Bartonitz, auf den Blog Akademie Integra gestoßen.

Der Post namens Die mutigste Entscheidung einer Gesellschaft dieses Blogs hat mich dabei ganz besonders gerührt, weil hier etwas thematisiert wird, welches auch Ankerpunkt meines Blogs ist, nämlich das Aufbrechen von Denkblockaden und das Umstürzen von Paradigmen. Genauer gesagt, besser hätte ich auf die Frage “Warum betreibst Du eigentlich Deinen Blog?” nicht antworten können, als es in diesem Post getan wird. Das ist auch mein Motiv, diesen Blog hier in einem dedizierten Post zu erwähnen.

Wie im Titel angedeutet, kranken wir häufig daran, Problemstellungen und Situationen nicht zu Ende zu denken. Nun könnte man natürlich auch sarkastisch entgegnen, dass man froh sein kann, dass Menschen überhaupt denken.

Was meine ich nun genau mit Zu-Ende-Denken? Das Zu-Ende-Denken bedingt eine Reflektion im Denken. Man könnte auch von Denken zweiter Ordnung sprechen. Nur durch dieses Zu-Ende-Denken kann man Probleme wirklich bei der Wurzel packen und sie damit lösen. Anderenfalls bleibt man bei der Symptombekämpfung stecken.

Das Zu-Ende-Denken bedingt auch das Aufbrechen von Denkmustern, die in früheren Zeiten zu Erfolg geführt haben, sonst hätten sich diese ja nicht etablieren können. Es geht also um das Validieren und Hinterfragen von Paradigmen, fern ab von der Devise “Das haben wir aber schon immer so gemacht.”

Ich möchte nachfolgend einige Beispiele aus der Praxis anführen, die Sie sicher kennen und das Gesagte untermauern sollen. An den Beispielen möchte ich darlegen, dass man oft mit einer Motivation startet, einen bestimmten Zustand anzustreben, sich dafür Handlungsmuster überlegt, dann aber diese Handlungsmuster als das Nonplusultra verkommen lässt, sie also nicht mehr auf Sinnhaftigkeit prüft. Ich nenne dieses Verhaltensmuster auch sehr gerne Methodizismus.

Beispiel 1: Diversity-Management in Unternehmen

In Unternehmen wird Unterschiedlichkeit angepriesen, was aus meiner Sicht auch erstrebenswert ist. Um diese Unterschiedlichkeit zu erreichen, wurde in vielen Unternehmen das Diversity-Management etabliert. Nimmt man diese Aktivitäten aber genau unter die Lupe, dann wird klar, dass mit diesen Vorhaben Bevorteilung von verschiedenen Gruppen (Gleichberechtigung ist die Erfindung eines Machthabers) gefördert wird.

Für Auswahlprozesse zur Besetzung bestimmter Positionen in Unternehmen haben sich Assessment Center als das Mittel der Wahl heraus gestellt. Allerdings wird mit den ACs und den dahinter liegenden Prozessen Gleichförmigkeit gefördert (Assessment Center finden in Höhlen statt).

Und beide Ergebnisse bestärken sich dann auch noch gegenseitig immer wieder neu. In Assessment Centern suchen Assessoren in der Regel sich selber aus. Sie bewerten also Kandidaten als positiv, die die gleichen Charakterzüge haben wie sie selber. Sie bestätigen sich damit implizit immer wieder neu. Damit schaffen sie eine Gleichförmigkeit, die sie durch Diversity-Management nachträglich korrigieren wollen.

Beispiel 2: Begrenztes Wachstum

Wir kennen alle das begrenzte Wachstum von Produkten (Paper Was hat Unternehmensführung mit Chaostheorie und Quantenmechanik zu tun?). Kreiert ein Unternehmen ein Produkt, welches sich im Markt sehr gut verkauft, ist stets irgendwann eine Marktsättigung erreicht. Das Produkt muss dann mit Features erweitert werden oder ganz neue Produkte müssen erfunden werden, damit das Unternehmen weiterhin Umsatz machen kann.

Diese Erkenntnisse sind mittlerweile in Unternehmen weit verbreitet und finden bereits in der einen oder anderen Form Beachtung. Nur was ist mit den Theorien, auf die diese praktischen Umsetzungen beruhen. Warum geht man häufig davon aus, dass diese Theorien eine unbegrenzte Lebensdauer haben. Das Gedankenkonstrukt eines unbegrenzten Wachstums sollte also auch auf die theoretischen Erkenntnisse ausgeweitet werden, von denen wir die Funktionsweisen für die Unternehmen abgeleitet haben. Hier könnte man sagen: „Wer A sagt, sollte auch konsequenterweise B sagen.“

Ich könnte hier eine ganze Reihe weiterer Beispiele nennen. Sie sicherlich auch.

1 Star2 Stars3 Stars4 Stars5 Stars (2 Bewertung(en), Durchschnitt: 5.00 von 5)
Loading...
Posted in Denken | Tagged , , | 2 Comments

Projekte stehen in der Regel für Mittelmaß

Folgende Beobachtungen mache ich immer wieder beim Aufsetzen und Durchführen von Projekten.

Es besteht eine Idee zu neuen Produkten, Prozessen etc. Man hat ein Ziel vor Augen, welches man erreichen möchte. Dann werden Projekte initiiert, die in dieses Ziel hinein arbeiten. In dem Moment, wo begonnen wird zu teilen, entstehen Silos und das Silodenken bekommt Nährboden.

Der Mitarbeiter, der für ein bestimmtes Projekt als Projektleiter eingeteilt wird, hat mit der Ernennung nur noch sein Projekt im Fokus. Hat man zu Beginn der Idee noch den Mehrwert im Fokus, den man mit den Projekten für sein Geschäft erringen möchte, rückt dieser Mehrwert immer mehr aus dem Blickwinkel. Der Projektleiter wird schließlich an seinem Projekt gemessen, nicht an dem Erfolg der anderen Projekte. Meist hängt daran über Auslobung von persönlichen Zielen in dem jeweiligen Geschäftsjahr eine mögliche Gehaltserhöhung für das nächste Jahr.

Es beginnen Diskussionen über den Scope einzelner Projekte. Jeder Mensch weiß, je geringer die Messlatte ist, an der er gemessen wird, desto einfacher ist es diese zu überspringen. Es wird also begonnen, knifflige Themen aus dem Projekt auszugrenzen, da diese hinderlich für den Projekterfolg und damit für den eigenen Erfolg als Projektleiter sein können. Risikominimierung.

Dieses Verhalten ist den meisten Projektleitern in Fleisch und Blut übergegangen, da sie nach genau dieser Art gesteuert werden. Sie bekommen es auch in den Schulungen und Seminaren zu Projektmanagement, egal welcher “Glaubensrichtung”, genau so ins Gebetsbuch gesungen. Nur was passiert hier?

In Summe sind dann die Projekte auf Mittelmaß ausgerichtet. Schon beim Aufsetzen der Projekte werden die lokalen Projektziele im Sinne eines Scope- und Risikomanagements nach unten korrigiert. Dann startet man. Hat man einmal Ziele nach unten korrigiert, ist man in einem Strudel gefangen und tut dies immer wieder. Dieses Verhalten ist unter dem Systemarchetyp Erodierende Ziele bekannt, den ich in meinem Post Verhaltensmuster im Projektmanagement Teil 1: Zielanpassungen detailliert beschrieben habe.

Projekte sind damit nicht nur auf Mittelmaß ausgerichtet, sie erreichen dieses auch in den meisten Fällen noch nicht einmal. Das folgende Bild zeigt die Zusammenhänge inhaltlich zusammengehöriger Projekte

Aufsetzen von Projekten_real

An dieser Stelle ist es auch egal, ob man Projekte in Teilprojekte zerlegt und diese dann von Teilprojektleitern steuern lässt oder ob man viele Projekte zu einem Programm zusammenfasst und die Integration darüber herstellen möchte. In dem Moment wo Silos errichtet werden, die auf lokale Zielerreichung ausgerichtet sind, ist Integration nicht mehr machbar, da nur noch nachrangig.

Jetzt kommt der Integrationsmanager ins Spiel. “Die arme Sau”. Denn dass Integration wichtig ist, wird Niemand bestreiten. Deshalb wird ja auch der Integrationsmanager institutionalisiert. Nur fühlt dieser sich sehr oft wie Don Quijote bei seinem Kampf gegen die Windmühlen. Er hat einfach keine Chance Integration herzustellen, da die Projekte mit Fortschritt dieser immer weiter auseinander driften, da die Ziele dieser erodieren. Dargestellt ist diese Konstellation in der obigen Graphik anhand der roten Pfeile zwischen den Projekten.

Ein anderer Fakt, der dieses Verhaltensmuster noch verstärkt, ist der Wechsel von Ergebnis- hin zu einer Prozessorientiertheit. Denn man könnte ja fragen, warum der oben beschriebene Wirkmechanismus nicht erkannt wird oder nichts dagegen unternommen wird.

Mit dem Ausloben der Idee ist man ergebnisorientiert. Dann macht man sich Gedanken dieses Ziel zu erreichen. Man initiiert Projekte wie oben beschrieben. Man verlässt immer mehr die Ebene der Ergebnisorientiertheit in Richtung Prozessorientiertheit. Die herkömmlichen Projektmanagementmethoden kommen zum Einsatz: Risikomanagement, Scopemanagement, Issuemanagement etc. Listen, die als Template bereit stehen, werden gefüllt und und und.

Wird hier gefragt, in wie weit diese Prozesse zu einem Erfolg führen oder wie groß der Mehrwert ist, der durch Ausführen dieser Prozesse auf eine Zielerreichung einzahlt? Nein. Viel zu selten wird der Sinn und Zweck von Prozessen hinterfragt. Es muss ja einen Grund geben, warum diese in der Vergangenheit definiert wurden. Mit diesen Prozessen wurden natürlich auch Rollen in Unternehmen installiert. Hinterfragt man Sinn und Zweck der Prozesse, hinterfragt man automatisch die Daseinsberechtigung dieser Rollen und damit der Menschen im Zusammenhang mit diesen Rollen. Das macht es dann umso schwerer dieser Prozessdenke zu entfliehen.

Ich habe zwei Gründe dargelegt, warum Projekte auf Mittelmaß gebaut sind und dieses nur schwer erreichen.

  1. Ganzheitliche zusammenhängende Ideen werden für die Umsetzung in verschiedene Projekte/ Teilprojekte aufgeteilt, die lokal gesteuert werden (Teile und herrsche klappt nicht). Dadurch geht die Ganzheitlichkeit und damit der eigentliche Mehrwert verloren, was aber nicht wahrgenommen wird, da …
  2. … die Ebene der Ergebnisorientiertheit verlassen und die der Prozessorientiertheit eingenommen wurde. Man stiefelt teilweise blind Best Practice Ansätzen hinterher, ohne Hinterfragung des Sinns dieser. Erschwert wird diese Diskussion durch die Emotionalität, die durch das Hinterfragen von Rollen geführt werden müsste, weshalb es einfach unterlassen wird. Dass man den Mitarbeitern damit aber mehr schadet, wird aus dem Fokus ausgegrenzt.

Die untere Abbildung stellt den aus meiner Sicht idealen Zustand des Wirkens von thematisch zusammenhängenden Projekten dar. Es gibt Überlappungen im Wirkkreis und in der Verantwortung von Projekten (grün schraffiert). Projektleiter müssen “über ihren Tellerrand” hin zu thematisch angrenzenden Projekten schauen und dies nicht den Integrationsmanagern überlassen. Ein Projektleiter eines Projektes ist mit verantwortlich für den Erfolg angrenzender Projekte und wird auch daran gemessen, genauso wie er an dem Erfolg seines Projektes gemessen wird.

Aufsetzen von Projekten_ideal

Man erkennt an der schematischen Darstellung auch sehr schön das Redundanzen erwünscht sind, gar notwendig sind. Lean ist an dieser Stelle schädlich. Projekte und Fließbandarbeit schließen sich gegenseitig aus. In Projekten wird Etwas Neuartiges geschaffen, das kann man sogar in den Definitionen der von mir oft kritisierten, da zu mechanistischen, Projektmanagementmethoden nachlesen. Verantwortlichkeiten sind doppelt und dreifach vergeben, nur so werden sie auch wirklich integrativ und ganzheitlich gelebt. Damit wird einer Abschottung und einem Auseinanderdriften der Projekte entgegengewirkt.

Den oben angerissenen Punkt 2 möchte ich in meinem nächsten Post reflektieren, in dem ich den Unterschied zwischen hierarchisch und heterarchisch geführten Unternehmensorganisationen reflektieren möchte. Die Ideen und Gedanken dazu würden den Umfang dieses Posts sprengen.

1 Star2 Stars3 Stars4 Stars5 Stars (2 Bewertung(en), Durchschnitt: 5.00 von 5)
Loading...
Posted in Management und Leadership | Tagged , , | 6 Comments

Business Intelligence zweiter Ordnung lebe hoch, aber …

Ich habe des Öfteren darüber referiert, dass BI aus meiner Sicht zu oft als Selbstzweck betrachtet wird. Hypewörter, wie “data-driven” oder “Big Data” verstärken diesen Effekt. BI wird in Unternehmen kontextlos betrachtet, was letztendlich dazu führt, dass BI Projekte zu technokratisch und technologiefokussiert aufgesetzt werden.

Der eigentliche Sinn von BI wird damit aber nicht tangiert. Um das näher zu erläutern, möchte ich erst einmal BI aus meiner Sicht definieren und daraus den Sinn von BI ableiten, bevor ich den am Anfang geschilderten Fakt an einem speziellen Beispiel darauf reflektiere.

Was ist eigentlich BI?

Unter Business Intelligence (ab sofort mit BI abgekürzt) verstehe ich das Beschaffen und Verwalten von Daten, um aus diesen Informationen zu generieren, die wiederum zum Bewerten und Untermauern von Entscheidungen in Unternehmen dienen.

BI ist also niemals kontextlos, sondern steht stets im Kontext der jeweiligen zu treffenden Entscheidungen in den jeweiligen Business Domänen (Einkauf, Vertrieb, Logistik, …).

Unter BI-Tool verstehe ich ein Sammelsurium verschiedenen technischer Funktionalitäten. Zum einen ist an dieser Stelle eine Datenbank zu nennen, mit einem für die jeweilige Anwendung, in diesem Fall “BI Anforderungs- und Releasemanagement”, adäquates Datenmodell. Des Weiteren spielt hier aber auch ein Frontend (Userinterface) eine Rolle, welches zur Eingabe von Daten dient, aber auch zur Ausgabe von Daten, die aus erkenntnistheoretischen Gesichtspunkten so dargestellt werden sollten, dass die Menschen daraus effizient und effektiv Informationen generieren können.

Was ist daraus abgeleitet der Sinn von BI?

Aus der oben gegebenen Definition leitet sich relativ leicht der Sinn von BI ab. Unternehmen benötigen BI, um ihr Business besser zu machen. Das Wort “besser” muss pro Unternehmen dediziert definiert werden. An dieser Stelle kommt für mich der Glaube ins Spiel. Manager müssen in bestimmten Domänen ihres Business, sei es nun Einkauf, Vertrieb, Logistik etc., einen Glauben darin entwickeln in wie ihnen Daten helfen können, um daraus belastbarere Informationen ableiten zu können, die wiederum zu einer belastbareren Entscheidungsgrundlage führen. Ich rede hier vom Glauben, da zum Zeitpunkt der Entscheidung, die auf diesen Informationen beruhen, der Manager nicht objektiv bemessen kann, ob die Entscheidung richtig ist. Diese Bewertung funktioniert stets in der Zukunft. Jede Entscheidung ist als eine Wette in die Zukunft.

BI darf also niemals kontextlos, wie in vielen Unternehmen der Fall, betrachtet werden, sondern stets im Zusammenhang mit der jeweiligen Businessdomäne und den Daten, die zu besseren Entscheidungen führen.

BI zweiter Ordnung

BI zweiter Ordnung

Diesen Sinn im Kopf habend, kommt man natürlich schnell dazu, BI auch für BI anzuwenden. BI zweiter Ordnung quasi. Genauer geht es mir darum, BI in Unternehmen für das BI Anforderungs- und Releasemanagement einzusetzen. Was meine ich damit genau?

Auf Basis dieser BI Anwendung kann man Anforderungen seitens der Fachbereiche besser verstehen. Mit diesem Tool kann man quasi auch Anforderungen, die in den Köpfen der Fachbereichsmitarbeiter unbewusst schlummern und nicht wirklich artikulierbar sind, heraus kitzeln, in dem fragenbasiert die Anforderungen erfragt und strukturiert dokumentiert werden.

  1. Müssen in diesem Prozessschritt Entscheidungen getroffen werden, die auf Analyse von Daten beruhen (Ich kann mir keine Situation denken, wo das nicht der Fall)? Wenn ja, beantworten der restlichen Fragen.
  2. Welche Merkmale/ Dimensionen benötigen Sie für die Analyse?
  3. Welche Kennzahlen sollen ausgewertet werden?
  4. Wie soll die Analyse dargestellt werden?
  5. Wer sind die Empfänger der Analyse?
  6. Wie aktuell müssen die Daten für die Analyse sein?
  7. Werden historische Daten benötigt? Wenn ja, bis wie lange in die Vergangenheit zurück sollten die Daten mindestens vorliegen?
  8. Muss die Analyse automatisch generiert und versendet werden?
  9. Wie oft und wann wird die Analyse benötigt?
  10. Benötigen Sie analytische Funktionalitäten, wie beispielsweise Data Mining?
  11. Welche Reportingszenarien kommen zum Einsatz (today-is-yesterday, yesterday-is-today, today-and-yesterday, today-or-yesterday)?

Hat man diese Anforderungen beiderseitig verstanden, Fachbereich und IT, und strukturiert dokumentiert, hat man eine Basis geschaffen, nachhaltige Entscheidungen zu fällen. In der IT entsteht so also die Möglichkeit haben, Anforderungen, die seitens des Business an BI gestellt werden, beispielsweise über Dashboards und Reports zu bewerten. Beispiele für konkrete Fragestellungen könnten sein.

  1. Bis zu welchem Grad können wir die Anforderung mit der derzeitigen Lösung bereits abdecken?
  2. Welche zusätzlichen Daten (Kennzahlen, Merkmale, …) benötige ich, um die Anforderung umzusetzen?
  3. Kann ich einen bestehenden Cube mit diesen Daten erweitern? Wenn ja, muss dafür die Berechtigungsteuerung auf diesem Cube angepasst werden?
  4. Existiert die angeforderte Kennzahl, die der Fachbereich anfordert bereits in meinem Datenmodell?
  5. Falls der Name dieser Kennzahl stimmt, ist auch die Semantik dahinter die gleiche? Wird die Kennzahl gleich berechnet?

Mein derzeitiges Feedback auf diese Anforderung

Diese Diskussion habe ich in verschiedenen BI-Foren in Xing platziert und habe für mich ernüchternde Antworten bekommen. Einen Geschmack davon können Sie beispielsweise hier gewinnen. Ich habe den Eindruck gewinnen müssen, dass meine Anforderung, BI für das Anforderungs- und Releasemanmagement im BI zu verwenden (übrigens macht der Einsatz von BI für das grundlegende Anforderungs- und Releasemanagement, nicht nur im BI, Sinn), nicht verstanden wurde. Das ist für mich aber auch nicht so verwunderlich, wenn ich mir das grundsätzliche Verständnis von BI in Unternehmen, wie am Anfang meines Posts geschildert, anschaue. Es bestätigt diese Sichtweise.

Wenn ich also für mein Business, beispielsweise Einkauf, Vertrieb, Unternehmensplanung und -steuerung BI einsetze, warum dann nicht für ein BI Anforderungs- und Releasemanagement? In allen Fällen geht es darum Entscheidungen auf Basis von Informationen zu treffen, die ich mir mit Hilfe von BI-Tools generieren kann.

Und noch etwas bleibt hinzuzufügen, was sogar für ein BI-Standardtool spricht. Ich glaube nicht, dass sich ein BI Anforderungs- und Releasemanagement branchen- und industrieübergreifend so arg unterscheidet. Auf keinen Fall werden die Anforderungen an solch ein Tool spezifischer sein, als sie es für die jeweiligen Businessdomänen sind. Und in diesen Bereichen sind wir sehr wohl bereit über den Einsatz von BI-Standardtools zu sprechen.

Ich bin der festen Überzeugung, hat man erst einmal den eigentlichen Sinn und Zweck von BI für den Einsatz in Unternehmen verstanden, kommt man nicht umhin, BI auch für das Anforderungs- und Releasemanagement für BI einzusetzen.

Dann möchte ich also den Titel dieses Posts finalisieren.

BI zweiter Ordnung lebe hoch. Dafür müssen wir aber erst einmal BI erster Ordnung aus dem Schlaf holen.

1 Star2 Stars3 Stars4 Stars5 Stars (2 Bewertung(en), Durchschnitt: 3.00 von 5)
Loading...
Posted in Management und Leadership | Tagged , , , | 6 Comments

Der Datenirrglaube – Wir leben (noch) nicht in einer Informationsgesellschaft

Ich war gestern auf einer BI Veranstaltung. Diese war sehr spannend und hat mich wieder einmal für ein Thema sensibilisiert, welches ich in meinen Posts zu Business Intelligence schon des Öfteren angerissen habe. Es geht um die Unterscheidung zwischen Daten und Information. Trifft man nämlich diese Unterscheidung, die ich im Folgenden an 4 Irrglauben deutlich machen werde, dann kommt man sehr schnell zu der im Titel dieses Posts postulierten Aussage.

Wir leben nicht in einer Informationsgesellschaft. Wir leben in einer Datengesellschaft.

Datenirrglaube

Irrglaube 1: Information wird immer mehr

Häufig höre ich die Aussage: “Wir müssen lernen mit der stetig steigenden Informationsflut umzugehen!”. Ich denke nicht, dass wir das lernen müssen, da wir uns dieser steigenden Informationsflut zurzeit gar nicht ausgesetzt sehen. Wir haben es mit einer steigenden Datenflut zu tun, nicht mit einer steigenden Informationsflut.

Ich möchte den Unterschied zwischen Daten und Information an einem Beispiel demonstrieren.

Stellen Sie sich einen Manager eines Unternehmens vor, der einen Bericht über die Umsätze seines Unternehmens im letzten Monat vorgelegt bekommt. In dem Bericht ist der Umsatz mit 500 Tsd. Euro ausgewiesen. Diese Zahl ist ein Datum, aber noch keine Information. Das Datum wird erst in dem Moment, wo der Manager diese Zahl liest und damit automatisch interpretiert, zu einer Information. Ein Datum ist objektiv. Eine Information ist stets subjektiv, da der Datenempfänger, in diesem Fall der Manager, das Datum gegen seine inneren Modelle validiert und wertet. Auf Basis der subjektiven Modelle kann man dann zu verschiedenen Wertungen und damit Information kommen.

  1. Super. Ich habe mit viel weniger gerechnet.
  2. Schlecht. Unseren Plan haben wir nicht erreicht.
  3. Genial. Unser neues Produkt haben wir hervorragend im Markt platziert.
  4. Mist. Eigentlich hätten wir mehr Umsatz machen müssen, da ja unser größter Wettbewerber Konkurs angemeldet hat.
  5. In diesem Bericht ist unser letzter Deal ja noch gar nicht eingeflossen. Also, alles gut.

Sicherlich finden Sie eine Reihe weiterer Optionen. Es ist relativ leicht ersichtlich, dass aus den unterschiedlichen Interpretationen auch unterschiedliche Handlungen abgeleitet werden. Und das ist ein weiterer Unterschied zwischen Information und Daten. Information ist handlungsleitend, Daten nicht.

Wir leben deshalb derzeit nicht in einer Informationsgesellschaft, weil wir immer weniger in der Lage sind, aus dem anwachsenden Datenvolumen, das Handlungsleitende und damit die Information zu extrahieren.

Aus diesen Argumenten wird schnell ersichtlich, dass wir beispielsweise in BI Projekten, viel mehr Augenmerk darauf legen sollten, Daten so aufzubereiten, dass diese von den Empfängern leicht und schnell zu Informationen verarbeitet werden können. Leider wird dieser Fakt ignoriert, da der Unterschied zwischen Daten und Information nicht präsent ist.

Zur Darstellungsweise von Daten verweise ich gerne auf Dr. Rolf Hichert und seine SUCCESS Regeln.

Irrglaube 2: Information ist nicht vergänglich

Auch hier hilft wieder, wie schon beim ersten Irrglauben, das Verständnis des Unterschieds zwischen Daten und Information. Ich möchte mich von zwei Seiten diesem Irrglauben nähern.

Von der einen Seite her kommend möchte ich mich für die Definition des Begriffes “Information” auf Gregory Bateson, angloamerikanischer Anthropologe, Biologe, Sozialwissenschaftler, Kybernetiker und Philosoph, stützen. Er sagte.

Information ist der Unterschied, der den Unterschied macht.

und hat diese Definition an einem folgenden einfachen Beispiel erklärt.

Man kann einem Hund einen Tritt geben, dass der Hund wegfliegt, oder man kann ihm einen Tritt geben, dass er weg rennt. Im ersten Fall gibt man die Energie, die den Hund bewegt, im zweiten Fall leistet der Hund seine Bewegung selbst, das heißt, man hat ihm nur Information, also in Bezug auf seine Bewegung nur sekundäre Energie gegeben.

Von der anderen Seite her kommend, möchte ich eine Aussage aufgreifen, die ich häufig höre, nämlich: “Information unterliegt im Unterschied zu Materialien, die man bearbeitet, bei Benutzung keinem Wertverfall.” Sie vergeht nicht. Sie ist immateriell. Materialien sind, wie der Name schon sagt materiell, sie vergehen. Aber kann man das so einfach stehen lassen?

Nun möchte ich beide Seiten vereinen. Information entsteht unter anderem durch Kommunikation. Daten werden vom Sender auf Empfänger übertragen und der Empfänger generiert aus diesen Daten Information für sich. Stellen wir uns einmal vor, Sie kennen meinen Namen nicht. Ich sage Ihnen: “Ich heiße Conny.”. Sie generieren daraus die Information, dass Ihr Gegenüber auf den Namen Conny hört. Jetzt sage ich Ihnen diesen Satz noch einmal: “Ich heiße Conny.”. Diese Daten müssen Sie nicht noch einmal in Information transformieren. Sie haben nichts Neues gehört. Sie kannten meinen Namen bereits. Bezüglich der obigen Definition von Bateson gibt es hier keinen Unterschied mehr und damit keine Information.

Information ist also in Bezug auf Kommunikation sehr wohl vergänglich, Daten, in diesem Fall der Satz “Ich heiße Conny.”, sind nicht vergänglich.

Details dazu finden Sie auch in meinem Post Mit System Dynamics Dynamiken und Verzögerungen von Handlungen verstehen. Hier tauche ich tiefer in Material- und Informationsströme ein und erläutere die Unterschiede und Auswirkungen.

Irrglaube 3: Datenqualität um jeden Preis

In vielen Unternehmen verkommt das Thema Datenqualität zum Selbstzweck. Es wird viel Aufwand spendiert, um die Qualität, wie beispielsweise Dubletten im Kundenstamm oder falsche oder fehlende Attributseinträge im Produktstamm zu korrigieren. Diesem Aufwand wird im Vorfeld aber kein Glaube bzgl. des Mehrwertes für das Business gegenüber gestellt. Damit meine ich beispielsweise, dass man seine Gedanken bzgl. der besseren Erreichbarkeit und Ansprache von Kunden im Rahmen von Marketingkampagnen und einem damit einhergehenden Umsatzanstieg auf Basis der besseren Dublettenrate im Kundenstamm thematisiert und verprobt.

Ich spreche an dieser Stelle mit Absicht von einem Glauben, denn Wissen kann es nicht sein, da es sich um die Zukunft dreht.

Ähnlich wie bei den beiden ersten Irrglauben muss man also auch bei diesem näher hinein leuchten. Datenqualität sollte man nicht über den großen Kamm scheren.

Es gibt sicherlich Bereiche, die eher im klassischen BI Bereich anzusiedeln sind, wo die Datenqualität nicht hoch genug sein kann. In diesem Kontext sind Fachgebiete wie Finanz oder Controlling zu nennen, wo man aus Wirtschaftsprüfungssicht genaue und exakte Daten in Berichten zeigen muss. Wenn ein Handelsunternehmen nicht die genauen und exakten Adressdaten seiner Kunden besitzt, wird es sicherlich schwer werden, die Pakete dem Kunden zu liefern.

Genauso gut gibt es aber Bereiche, wo es eher auf andere Aspekte als auf Datenqualität ankommt, wissend, die Zeit nicht spendieren zu können, Datenqualität herzustellen, da das auf Kosten der Agilität geht. In diesem Kontext geht es dann um neuartige BI Anforderungen, die sich hauptsächlich um das Web drehen. Wenn beispielsweise Kunden für bestimmte Marketingkampagnen selektiert werden müssen, ist die Qualität des Kundenstamms nicht bis ins letzte Korn relevant.

Daten entstehen eben wie sie entstehen und in der heutigen Zeit in immer unstrukturierteren Umgebungen des Internets. Hier macht es keinen Sinn, Datenqualität “auf Teufel komm `raus” herstellen zu wollen. Das WOZU der Datenqualität muss stets in den Aufwänden reflektiert sein.

Irrglaube 4: Der Single-Point-of-Truth ist anzustreben

Unternehmen laufen seit sehr langer Zeit dem Paradigma hinterher, dass die eine einzige Wahrheit in den Daten die Welt rettet. Es gibt aber eben nun mal nicht die eine einzige Wahrheit, da diese dann kontextlos wäre, also die fachlichen Anforderungen an die Daten ignorieren würde.

Ähnlich wie beim dritten Irrglauben ist auch hier wieder der Mehrwert, den man sich für das Business erhofft und an dem man glaubt, entgegen zu setzen. Je nach Anwendungsgebiet (Vertrieb, Einkauf, Logistik, Kreditmanagement etc.) sind unterschiedliche Anforderungen an Daten umzusetzen. Hier macht es keinen Sinn mit der großen Schaufel anzusetzen, da je nach Bereich auch konkurrierende Anforderungen an Daten existieren können, die man nicht übereinbringen kann und auch nicht muss.

Die Wahrheit in den Daten muss man stets gegen die Nutzung der Daten in den jeweiligen Anwendungsgebieten spiegeln, damit man der Kontextlosigkeit entflieht. Und damit wird dann auch das Wörtchen “single” obsolet.

Details zu diesem Irrglauben habe ich im Post Business Intelligence – Das Konstrukt eines Core Datawarehouse ist überalterten Paradigmen geschuldet nieder geschrieben.

1 Star2 Stars3 Stars4 Stars5 Stars (2 Bewertung(en), Durchschnitt: 5.00 von 5)
Loading...
Posted in Ökonomie und Wirtschaft, Wissen | Tagged , , , , | 4 Comments

Virtuelle Ausgabe des System Dynamics Review zum Projektmanagement

Projekte sind stets höchst dynamisch und finden dazu auch noch in dynamischen Umfeldern statt. Deshalb ist es umso wichtiger, das Management der Projekte auf diese Dynamik einzustellen, was leider viel zu häufig missachtet wird, wenn man sich die herkömmlichen Projektmanagementmethoden anschaut.

Eine Möglichkeit des Einbeziehens der Dynamik in Entscheidungssituationen in Projekten ist die Modellierungsmethode System Dynamics.

SD Review

In diesem Post möchte ich auf die erste virtuelle Ausgabe der Wiley Online Library verweisen. In dieser Ausgabe wird System Dynamics auf Projektmanagement angewandt. Durch Klick auf das neben stehende Bild gelangen Sie in die komplette Ausgabe. Unten habe ich Ihnen den Inhalt dieser Ausgabe inklusive der Autoren gelistet. Durch Klick auf die einzelnen Beiträge öffnen Sie diese direkt. Viel Spaß beim Erkenntnisgewinn.

Inhalt

System dynamics applied to project management: A survey, assessment, and directions for future research
James M. Lyneis and David N. Ford

Software productivity: Potential, actual, and perceived
Tarek K. Abdel-Hamid and Stuart Madnick

Dynamic modeling of product development processes
David N. Ford and John D. Sterman

A dynamic model of resource allocation in multi-project research and development systems
Nelson P. Repenning

Why firefighting is never enough: Preserving high-quality product development
Laura J. Black and Nelson P. Repenning

Tipping point dynamics in development projects
Tim Taylor and David N. Ford

Dynamics of concurrent software development
Hazhir Rahmandad and David M. Weiss

System dynamics in project management: A comparative analysis with traditional methods
Alexandre Rodrigues and John Bowers

Strategic management of complex projects: A case study using system dynamics
James M. Lyneis, Kenneth G. Cooper and Sharon A. Els

Bibliography

 

1 Star2 Stars3 Stars4 Stars5 Stars (1 Bewertung(en), Durchschnitt: 5.00 von 5)
Loading...
Posted in Modellierung | Tagged , , | Leave a comment