Skip to content

  Aktuelle Informationen

ihre worte - neu geschrieben
  Gebhard Roese - Ihr Texter, Schriftsteller und Journalist.
  Mobil 016093095395.

Problemlösungen: Warum scheitern eigentlich Data Warehouses?

Sie wundern sich über den Titel? Außer zur Schrifttellerei hab ich immer noch einen kleinen Draht zu Kommunikation und zu Problemlösungen. Sie dürfen sicher sein: Die meisten erkannten Probleme werden deshalb nicht gelöst, weil die Grundlagen unzureichend ermittelt wurden.

Wer schon seit längerer Zeit nicht mehr in der IT-Branche arbeitet, so wie ich, der darf sich zurücklehnen und den Ameisenhaufen „Wirtschaftsunternehmen“ einmal von außen betrachten.

Ich greife „Data Warehousing“ heraus, weil es eines der Gebiete ist, die für die Unternehmenspolitik, namentlich die des Vertriebs, von entscheidender Bedeutung sind. Heute sagt man gelegentlich nicht mehr „Data Warehouse“, sondern „Data Mart“, und manche Menschen finden es unheimlich wichtig, die Unterschiede zu erläutern. Allein dies Beispiel einer an sich wertlosen Definition zeigt, wie wuselig die IT-Branche ist, von der man doch glaubt, sie sei von kühlen Analytikern durchsetzt. "Data Warehousing" bedeutet nichts anderes als die sinnreiche Bereitstellung von Unternehmensdaten. Zur Erinnerung: ein "Warehouse" ist ein Lager - weiter nichts.

Sehe ich heute ins Internet, so finde ich zahllose Artikel, die sich darum drehen, wie sich Datenstrukturen, Software, Hardware und „Endgeräte“ einsetzen lassen. Ich finde detaillierte Pläne als Powerpoint-Präsentationen, die sehr eindrucksvoll sind und von großem Fleiß der meist jungen Autorinnen und Autoren zeugen. Ich vermisse einen Satz: Die umfassende Analyse der Grundlagen.

Ansprüche, Wünsche, Hoffnungen - für IT-Lösungen irrelevant

Lassen Sie mich einen Moment Luft holen und Ihnen dies sagen: Die meisten Projekte dieser Art beginnen mit Wünschen, Ansprüchen und Hoffnungen – also mit „weichen“ Daten, für die es keine IT-Lösungen gibt.

Ich habe meinen Kunden und Schülern immer gesagt:

Mit Datenverarbeitung bilden Sie die Wirklichkeit ab. Nur, wenn ihre Wirklichkeit stimmt, stimmt später auch die Verwirklichung des IT-Projekts.


Wenn die Wirklichkeit zweifelhaft ist, passiert etwas, das IT-Leute „Shit in – Shit out“ nennen und was man in klarem Deutsch so ausdrücken könnte:

Das Ergebnis der späteren Analysen kann nicht besser sein als die Qualität der ursprünglichen Daten.


Strukturen müssen eindeutig sein

Das Geheimnis eines IT-Projekts liegt also in erster Linie in dem, was wir „die Wirklichkeit“ nennen könnten – und das Scheitern setzt da ein, wo die Grundlagen nicht stimmen. Ich will nicht unbedingt aus der Schule pluadern, aber so viel kann sich sagen:

Alle sogenannten „gewachsenen“ Strukturen müssen infrage gestellt werden können. Unternehmer, oder besser Manager, die sich dagegen wehren, müssen sich klar sein, dass sie damit das Projekt gefährden oder gar unmöglich machen. Üblicherweise liegen die Probleme in Abteilungs- Kunden- oder Produktstrukturen. Ich sage keinem IT-Mitarbeiter etwas Neues, wenn ich unterstelle, dass „kleinste verfügbare Einheiten“ geschaffen werden müssen, die sich auch bei strukturellen Veränderungen immer wieder sinnreich und vor allem schnell zusammensetzen lassen.

So selbstverständlich diese Tatsache für IT-Mitarbeiter ist, so utopisch scheint sie für viele Manager zu sein. Ich will hier nicht ins Detail gehen – aber dieses Szenario ist gewiss nicht unüblich:

Es gibt mehrerer Produktlinien, die aber keine Spur von Hierarchie aufweisen. Parallel dazu besteht eine zweite Gliederung, die mit der Ersten nicht in Einklang gebracht werden kann. Aus beiden sollen später wertvolle Fakten gewonnen werden, die für Unternehmensentscheidungen verwendet werden sollen. Das können sie aber nicht, weil sie nicht eindeutig genug sind.

Nun geschieht im Vorfeld des Projekts etwas sehr Merkwürdiges: Entweder, man hört auf den IT-Berater und begradigt die „Unebenheiten“ in den Strukturen, oder aber man hört auf die Abteilungsleiter, die für jede Unebenheit eine Sonderlösung wollen. Nimmt man sich der Wünsche der Abteilungsleiter an, so wird das Projekt mit Sicherheit komplizierter, sehr wahrscheinlich erheblich teurer und leider eben auch mit dem Virus des Versagens infiziert.

Wenn Ihnen das zu simpel ist, lesen Sie meinetwegen andere Meinungen, die mit Fremdwörtern gespickt sind. Aber vergessen Sie bitte nie: Wenn der Baugrund nicht stimmt, stürzt ihr schönes Data Warehouse irgendwann zusammen.

Brauchbar fand ich diesen Artikel, der nicht zu akademisch geschrieben ist.

Trackbacks

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Noch keine Kommentare

Kommentar schreiben

Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.

Um maschinelle und automatische Übertragung von Spamkommentaren zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben wurde, kann der Kommentar angenommen werden. Bitte beachten Sie, dass Ihr Browser Cookies unterstützen muss, um dieses Verfahren anzuwenden.
CAPTCHA

Formular-Optionen

Kommentare werden erst nach redaktioneller Prüfung freigeschaltet!