Wenn Sie die Seite nicht korrekt angezeigt bekommen, dann folgen Sie bitte diesem Link.

its-people GmbH
Newsletter Ausgabe: Nr. 03/2010 vom 15. März 2010

Liebe(r) Leserin,

Wenn Sie diesen Newsletter lesen, hat die CeBIT 2010 bereits wieder "ihre Tore geschlossen". Auch in diesem Jahr waren viele Kollegen von its-people, bcs-people sowie der enterpriser in Hannover, um sich über die wesentlichen aktuellen Trends zu informieren. Hier sind, aus unserer Perspektive, besonders die Themen "Cloud Computing" (der Schwerpunkt unserer "SOA - Quo Vadis-Veranstaltung" am 23. März 2010 in Frankfurt), "Green IT" und "Mobiles Social Networking" zu nennen.

Aber auch das Schwerpunktthema unseres heutigen Newsletters "Business Intelligence" (BI) nahm, wie in den Vorjahren, einen breiten Platz ein. Schlagzeilen lauteten u.a. "Microsoft zeigt neue Lösungen für Virtualisierung und Business Intelligence", "Business Intelligence-Lösungen von SAP können Verwaltungen bei der Auswertung großer Datenbestände, beim Reporting und Controlling unterstützen" bzw. "Deploying Oracle Business Intelligence EE on Solaris and Sun SPARC Systems”.

Und auch die Fachbeiträge in diesem Newsletter liegen voll im Trend:

  • Neartime Warehouse: Basierend auf dem Erfahrungsbericht eines Projektes aus der Financial Services Branche, wird vorgestellt, wie es gelungen ist, eine Beschleunigung der relevanten Informationsverarbeitungsprozesse, unter Zuhilfenahme der unter dem Stichwort Enterprise Application Integration (EAI) diskutierten Ansätze, zu erreichen.
  • Enterprise Data Warehouse (EDW): EDW kann man verstehen als die Summe aller unternehmensweit gültigen "Spielregeln", die die BI Entwicklung in geordnete Bahnen lenken. Das EDW-Konzept beinhaltet konkrete Regeln, die man entlang der vier Aspekte "Fachlichkeit", "Prozesse", "Organisation" und "IT-Architektur" systematisieren kann.
  • Datenqualität: Die Widersprüche zwischen Informationen verschiedener Quellsysteme und deren Auswirkungen auf Datawarehouse-Systeme und BI-Lösungen stellen in vielen unserer Projekte eine Herausforderung dar. An dieser Stelle sei angemerkt, dass sich its-people stark im Thema "Bereichsübergreifendes Qualitätsmanagement von Kundendaten" im Rahmen der Oracle Solution Partner Community "Business Intelligence" engagiert.
Und "nach der CeBIT ist ja bekanntlich vor...". Am 16. März findet im Rahmen der Oracle OPN Days das nächste Meeting der Community BI statt und am 17. März folgt die DING Fachtagung (vormals deutschsprachige Informatica-Nutzergruppe). Bei beiden Veranstaltungen sind wir natürlich vertreten!
Bleibt zu erwähnen, dass its-people seit 2009 ein erstes BI-Projekt im Bankensektor, welches auf IBM-Technologie aufsetzt (InfoSphere Data Stage), unterstützt.

Fazit: BI ist und bleibt eines unserer spannendsten und innovativsten fachlichen Themen!

Wir wünschen Ihnen viel Spass beim Lesen, einen schönen restlichen März und ...
immer die richtigen Menschen in Ihren Projekten!

Herzliche Grüße


Thomas Algermissen Thomas Kraemer
Geschäftsführung Geschäftsführung

Thomas Algermissen
Thomas Algermissen
Thomas Kraemer
Thomas Kraemer
Inhaltsverzeichnis

Auf den Punkt gebracht
Aus der Praxis für die Praxis
Zukunftsbilder

top

Auf den Punkt gebracht


Veranstaltungsankündigung

"SOA Quo Vadis 2010 - Cloud Computing" am 23.3.2010 in Frankfurt
Vernetzte IT-Systeme sind heute geschäftliche Kernelemente, ohne die kein größeres Unternehmen mehr existieren kann. Gleichzeitig mutierten viele IT-Landschaften zu komplexen Technologie-Monstern, die viel Geld verschlingen und Time to Market sowie die Flexibilität der Unternehmen bedrohen. Cloud Computing als Baustein auf Basis serviceorientierter Architekturen (SOA) scheint einen Ausweg zu versprechen. Doch welcher unternehmerische Nutzen und welche Risiken stecken wirklich hinter dem Hype-Thema Cloud-Computing?
Und wie sieht Cloud Computing in der Realität auf einer heutigen Oracle Architektur aus?
Dies ist das Thema des vierten gemeinsamen Kooperations-Workshops von Oracle und its-people " SOA Quo Vadis 2010 - Cloud Computing ".
Die genaue Agenda und weitere Informationen zum Workshop finden Sie unter http://workshop.its-people.de.


its-people Köln feiert 5-jähriges Bestehen

Am 24. März 2010 feiert die its-people Köln GmbH ihr 5-jähriges Bestehen. Das Unternehmen hat es dank seiner ständigen Marktaktivitäten sowie der hohen Qualitätsansprüche geschafft, stetig zu wachsen und sich im Bereich SAP-Beratung am Markt der IT-Dienstleister zu etablieren.
Die Einstellung "nur zufriedene Kunden bleiben Kunden" und der hohe Qualitätsanspruch haben zu dieser Entwicklung geführt.
Bernd Schrader, Geschäftsführer der its-people Köln GmbH: "Der 5. Geburtstag ist für uns ein besonderer Tag, und wir sind stolz darauf, uns in wirtschaftlich schwierigen Zeiten auf dem Markt behauptet zu haben. In den nächsten Jahren erwarten wir weiteres Wachstum, das wir mit unserem Partnernetzwerk generieren werden."
Auf eine Geburtstagsfeier wird verzichtet; stattdessen erhalten die SOS-Kinderdörfer eine Spende.


Rating - nicht nur eine Sache der Banken!
Autor: Michael Siemon, Partner der bcs-people automotive GmbH

Diese Ansicht vertritt Michael Siemon auf Grund seiner Erfahrung als Banker, Controller und Certified Rating Advisor (BdRA).

Die Kreditvergabe und Konditionsgestaltung von Banken wird im Wesentlichen durch das interne Ratingverfahren einer Bank beeinflußt und ermittelt die Bonität des Kunden/Schuldners hinsichtlich einer künftigen Ausfallwahrscheinlichkeit. Dabei wird der Fokus größtensteils auf quantitative Informationen (Bilanz, GuV, Anhang) gelegt und berücksichtigt selten die qualitativen Aspekte (z.B.: Managementleistung, Prozesse) einer Unternehmung. Die Einschätzung ihres Unternehmens basiert damit nicht auf allen relevanten und verfügbaren Informationen und kann somit zu einer nicht optimalen Ratingnote führen.

Was kann man tun?

Sie wollen für sich auf Bank- und Investorengespräche vorbereiten oder bereits im Vorfeld ihr Standing bei Banken, Investoren und für sich selbst erfahren, dann ist der Ersatz eines externen Rating-Advisor zu empfehlen.

Durch Einsatz eines zertifizierten Rating-Advisor werden die Inhalte der Objektivität, Glaubwürdigkeit, Unabhängigkeit und Transparenz sichergestellt.

Wir arbeiten als Rating-Advisor entsprechend dem IOSCO-Code (International Organization of Securities Commissions) und nutzen für die Bewertung der einzelnen Sachverhalte die validierte Ratingsoftware R-Cockpit Edition 2009, ein Produkt der PSR Rating GmbH Tübingen. Die Erhebung der Informationen erfolgt im Interviewmodus, unterstützt durch die qantitativen Informationen.

Sie erhalten ein Gutachten, das die Sichtweise von Banken und Investoren abbildet. Ein Maßnahmenkatalog zeigt ihnen Aktivitäten auf, wie sie eine Verbesserung ihrer Ratingnote erreichen können. Neben dem Anspruch für Kreditgeber ist aber auch ihr internes Optimierungspotenzial sichtbar und für sie transparent.

Ansprechpartner: Michael Siemon, Partner der bcs-people automotive GmbH, Certified Rating Advisor (BdRA), Tel: 0175 5212019

top

Aus der Praxis für die Praxis


Erfahrungsbericht bzgl. der Umstellung auf ein Neartime Warehouse im Financial Services Umfeld
Autor: Sven Bosinger, its-people Hochtaunus

Motivation

Unternehmen der Finanzdienstleistung sind zunehmend international aufgestellt. Dies bedeutet, dass sie in fast allen Zeitzonen der Welt Geschäftsstellen besitzen, die zum Einen Daten an ein zentrales Data Warehouse (DWH) liefern und zum Anderen auf dieses DWH mit diversen Applikationen zugreifen. Dies hat zur Konsequenz, dass das betrachtete DWH rund um die Uhr mit aktuellen Daten versorgt werden muss. Es gibt also keine klassische Aufteilung zwischen nächtlichem Ladelauf und untertägiger Beauskunftung. Ladeläufe und Abfragen konkurrieren permanent miteinander. Darüber hinaus ist die Notwendigeit vorhanden, dass neue Quelldaten immer schneller in ein DWH integriert werden müssen und quasi sofort in Auswertungen eingehen müssen.

Aufgabenstellung

Um der Internationalisierung seines Geschäfts Rechnung zu tragen, sollte eine Umstellung der Ladeprozesse weg von einem klassischen Ladelauf hin zu einem permanenten Laden der Daten erfolgen. Dabei sollte die Architektur des Systems so gewählt werden, dass ein paralleles Laden von Daten und die gleichzeitige Abfrage auf die Fakttabellen zu keinen Engpässen im Datenbanksystem mehr führen. Zusätzlich sollte die Informationslatenz, also der Zeitpunkt der Anlieferung bis zum Einbau der Information in die Faktentabelle reduziert werden, so dass diese Latenz im Normalfall eine Stunde nicht überschreitet.

Lösung

Kern der Lösung bildet die konsequente Umstellung der Ladeprozesse weg von einem Batch-orientierten Verfahren hin zu ereignisgesteuerten Services. Dies betrifft mehrere Bereiche:

  1. Anlieferung:
    Die Anlieferung der Daten wurde von ASCII-Files auf ein EAI-Werkzeug umgestellt. Dieses bekommt Datenänderungen der Quellsysteme über Change Data Capture mitgeteilt und propagiert diese Änderungen in den Stage- Bereich des DWH. Der Einsatz des EAI-Werkzeugs hat den Vorteil, dass Quelldaten unterschiedlicher Technologien (z.B. SAP, Legacy, etc.) auf die Zieltechnologie Oracle transaktionsgesichert abgebildet werden.
  2. Konsolidierung:
    Die Konsolidierung und Verknüpfung der unterschiedlichen Quelldaten miteinander, wird nicht mehr über einen "klassischen ETL-Prozess" gewährleistet, sondern über diverse Integrationsservices, die aktiviert werden, sobald ein Datensatz im Stage-Bereich abgelegt wurde. Diese Services sorgen dafür, dass für jeden eingehenden Datensatz die notwendigen Prüfungen vorgenommen werden. Sind diese positiv ausgegangen, wird der Datensatz in das zentrale Datenrepository übernommen, d.h. in den entsprechenden Tabellen des DWH Enterprise Modells eingefügt und mit entsprechenden Schlüsseln versehen.
  3. Aggregation und Aufbereitung:
    Jede Veränderung im zentralen Datenrepository wird in entsprechenden Log-Tabellen festgehalten (MView-Logs). Diese Log-Tabellen werden dazu benutzt die Aggregat-Tabellen des Präsentations-Layers (Data- Marts) zu aktualisieren. Die Aggregate sind dabei als sogenannte Materialized Views ausgeprägt. Die Aktualisierung erfolgt ca. alle 5 Minuten.
Die Komplette Beladung des DWHs erfolgt nun ereignisgesteuert. Dabei ist das erste Ereignis die Erzeugung der Information im Quellsystem. Diese wird durch das EAI- Werkzeug registriert und in das DWH propagiert. Das "Anladen" des Datensatzes im Stage-Bereich löst sofort dessen Überprüfung mit anschließender Übernahme ins zentrale Datenrepository aus. D.h. es gibt keine übergeordnete Batch-Instanz, die zu festen Zeiten ein Laden der Daten initiiert und steuert. Lediglich die alle 5 Minuten stattfindende Aktualisierung der aggregierten Fakt-Tabellen ist nicht ereignis-, sondern zeitgesteuert. Dies ist der Performance geschuldet, da eine ereignisgesteuerte Fortschreibung der Aggregat-Tabellen unverhältnismäßigen Ressourcenaufwand bedeutet hätte. Die Vorgabe der maximal einstündigen Informationslatenz wird auch so allemal erreicht.
Der uneingeschränkte Zugriff durch die Reportingwerkzeuge auf die Fakt-Tabellen wird durch das Oracle Verfahren Partition Exchange Loading unterstützt. Dabei wird bei den partitionierten Fakt-Tabellen die jeweils neue Partition vor berechnet und dann an die schon vorhandenen Partitionen angehangen. Dadurch hat der Endbenutzer keine Log- Problematiken, die eventuell verhindern würden, dass er kurzfristig auf gesperrte Sätze keinen Zugriff hat.

Fazit:

Durch die Umstellung auf ein ereignisgesteuertes Laden des DWHs unter Einsatz von Technologien wie Materialized Views und Partition Exchange Loading ist es gelungen, die Informationslatenz auf deutlich unter einer Stunde zu drücken. Ergänzend dazu ist die Verfügbarkeit der Fakten-Tabellen deutlich gesteigert worden. Damit ist die Zukunftsfähigkeit des DWH gesichert worden.

Wenn Sie weitere Informationen wünschen oder Fragen haben wenden Sie sich an: sven.bosinger@its-people.de


Datenqualität - wie sagt man es dem Quellsystem?
Autor: Jens Behring, its-people Hochtaunus GmbH

Ein Problem, welches sich in vielen DWH-Systemen findet, ist die Datenqualität. In vielen Fällen ist ein DWH die erste Instanz, die in der Lage ist, Widersprüche zwischen verschiedenen Quellsystemen aufzudecken. Wenn dies geschehen ist, stellt sich die Frage, welches Quellsystem über den Widerspruch zu informieren und für die Auflösung des Widerspruchs zuständig ist.

Im konkreten Fall stellten sich ähnliche Probleme. Insgesamt sechs Quellsysteme stellten in der ersten Phase Daten bereit. Allerdings sollte das Prüfungskonstrukt weitere Quellsysteme akzeptieren können, ohne dass die erstellten Programme angepasst werden müssen. Aus verschiedenen Gründen wurde entschieden, dieses Prüfungskonstrukt komplett innerhalb der Datenbank in PL/SQL zu realisieren und auf graphische Oberflächen zu verzichten.

Prüfungen
Zunächst einmal wurden Vorgaben bzw. Tatsachen für die Prüfungen gesammelt:

  • Jede Prüfung kann in einer Datenbank als "Select"-Anweisung dargestellt werden
  • Jedes Quellsystem liefert einen Primärschlüssel
  • Jede Prüfung wird genau einem Quellsystem zugeordnet, welches sich um die Behebung des Widerspruches zu kümmern hat (auch wenn der Fehler in einem anderen Quellsystem liegt)
Für jedes Quellsystem wurde nun festgelegt, welche Datenfelder für eine Widerspruchsbehebung wichtig sind. Hierzu zählen natürlich der Primärschlüssel und die eigentliche Fehlermeldung. Dazu kommen einige Datenfelder, die die Bearbeitung des Widerspruchs vereinfachen. Alle Prüfungen wurden in Form einer "Select"-Anweisung in eine Tabelle eingetragen und einem Quellsystem zugeordnet. Alle "Select"-Anweisungen zu einem Quellsystem müssen dabei dasselbe Format haben, d.h. mit einer "Union-All"-Anweisung zu verbinden sein. Weiterhin sind die Prüfungen durch einen Schalter aktivierbar bzw. deaktivierbar. Kommen nun neue Prüfungen oder gar ganze Quellsysteme hinzu, müssen diese nur in Katalogtabellen eingetragen werden und werden durch die parallel zu den Tabellen erstellte API berücksichtigt.

Information des Quellsystems
Nachdem nun die Widersprüche gefunden wurden, mussten noch die Quellsysteme über diese informiert werden. Da es in allen Quellsystemen Felder gab, die eine Zuordnung zu Standorten ermöglichten, wurden diese für den Informationsprozess ausgewählt. Für alle Quellsysteme gibt es noch einen zentralen Ansprechpartner, der für Datensätze zuständig ist, bei dem das erwähnte Zuordnungsfeld nicht gefüllt ist. Nun wurden jedem Standort ein oder mehrere E-Mail-Empfänger zugeordnet, die die Abarbeitung der Widersprüche koordinieren. Die Widerspruchs-API generiert nun für jeden Standort eine Mail inklusive der gefundenen Widersprüche. Zusätzlich dazu werden noch Statistik-Mails generiert, die den aktuellen Stand der Fehleranzahl dokumentieren.

Das beschriebene Konstrukt ist inzwischen ohne große Änderungen seit über 5 Jahren im Einsatz. Es wurden lediglich Anpassungen vorgenommen, die sich durch neue Datenbank-Versionen und damit verbundene neue Möglichkeiten ergeben haben. Jede Woche werden auf diese Art und Weise ca. 500 Prüfungen abgearbeitet und 110 Mails versendet. Gestartet wurde mit ca. 300 Prüfungen, d.h. im Laufe der Jahre kamen noch 200 Prüfungen hinzu - und das ohne die Ladeprozesse des DWH anfassen zu müssen. Zurzeit werden ca. 3.000 Fehlermeldungen pro Woche durch die Prüfungen ermittelt. Gestartet wurde bei weit über 15.000. Und auch die 3.000 wären zu reduzieren, allerdings bedarf es hier Änderungen an den Prozessen innerhalb des Unternehmens, um alle Standorte zur Abarbeitung der Widersprüche zu animieren.

Das vorgestellte Konstrukt löst keine Datenqualitätsprobleme - aber es hilft, diese in Kombination mit entsprechenden organisatorischen Prozessen innerhalb des Unternehmens in den Griff zu bekommen.

Wenn Sie weitere Informationen wünschen oder Fragen haben wenden Sie sich an: Jens.behring@its-people.de

shaking hands

top

Zukunftsbilder


Enterprise Data Warehousing - ein Konzept nicht nur für große BI Implementierungen
Autor: Dr. Gunnar Schirp, assoziierter Berater der its-people Köln

Ausgangssituation
Warum ist Enterprise Data Warehousing wichtig?

Business Intelligence (BI) Lösungen - z.B. auf Basis von SAP NetWeaver BW - sind mittlerweile in vielen Branchen und Geschäftsbereichen eingeführt. Auch Unternehmen kleinerer und mittlerer Größe implementieren bspw. bei einer SAP BW Einführung oft nicht nur den mitgelieferten SAP Business Content, sondern setzen darüber hinaus spezielle Anforderungen durch kleinere Entwicklungsprojekte um. Hierin unterscheiden sich BI-Einführungen oft von ERP-Projekten.

Aufgrund der vielen Freiheitsgrade und Möglichkeiten in der Entwicklung besteht schnell die Gefahr des Wildwuchses: So hat die technische Machbarkeit oft Vorrang vor einer strukturierten Vorgehensweise, Interne und Externe Mitarbeiter "kultivieren" ihre jeweiligen Programmierstile, und fehlende Dokumentation erschwert die Wartbarkeit.

Es werden zwar schnell erste Erfolge erzielt, aber das mittelfristige Ziel, einen qualitätsgesicherten und konsolidierten Datenbestand für alle Unternehmensanalysen aufzubauen, verliert man leicht aus den Augen. Die Folge kann dann sein, dass Entscheider mit widersprüchlichen Kennzahlen konfrontiert werden, die Umsetzung neuer Anforderungen zu lange dauert oder die Datenqualität bemängelt wird.

Enterprise Data Warehousing (EDW) zielt darauf ab, dieser möglichen Fehlentwicklung einen Riegel vorzuschieben. Das Konzept ist nicht neu, oft aber rein "technologiegetrieben" und damit in seiner Wirkung begrenzt.

Dabei ist EDW nicht nur für große, sehr komplexe Organisationen relevant. Auch bei kleineren und mittelgroßen BI-Einführungen ist ein EDW-Konzept wichtig, wenngleich eine den organisatorischen und personellen Gegebenheiten entsprechende "smarte" Lösung gefunden werden muss.

Was versteht man unter Enterprise Data Warehousing?

Enterprise Data Warehousing kann man verstehen als die Summe aller unternehmensweit gültigen "Spielregeln", die die BI Entwicklung in geordnete Bahnen lenken. Das EDW-Konzept beinhaltet konkrete Regeln, die man entlang der vier Aspekte "Fachlichkeit", "Prozesse", "Organisation" und "IT-Architektur" systematisieren kann. So sind z.B. folgende Regeln auch bei kleineren BI-Implementierungen sinnvoll:

  • Fachlichkeit: Unterschiedliche Anwender verwenden oft gleichlautende Kennzahlen, benutzen aber unterschiedliche Berechnungsformeln. Als wichtigste Maßnahme ist hier in erster Linie der Aufbau eines unternehmenseinheitlichen Kennzahlenkatalogs sowie eines Geschäfts-Glossars zu nennen.
  • Prozess: Eine BI-Lösung "lebt" in der Regel in dem Sinne, dass ständig neue Wünsche generiert werden. Um hier den Überblick nicht zu verlieren ist z.B. der Ablauf bei der Aufnahme und Umsetzung neuer oder geänderter Anforderungen festzulegen ("Change Request-Verfahren").
  • Organisation: BI muss nicht nur technisch von der IT betrieben werden, auch bei kleineren Lösungen sind dauerhaft bestimmte fachliche Rollen zu besetzen, z.B. die inhaltliche Hoheit und Verantwortung für bestimmte Kennzahlen und Daten ("Key-User", "Data Stewards").
  • IT-Architektur: Kernelement der IT-Architektur ist die Implementierung eines sogenannten "single-point-of-truth", einer detaillierten, historisch vollständigen und verwendungsneutralen Datenschicht, aus der sich alle Unternehmensanalysen speisen. Weitere Bausteine sind z.B. ein Namenskonzept für Entwicklungsobjekte und Queries, Dokumentationsstandards oder Regeln für die Verwendung des SAP Business Contents.
Ein echter Quantensprung in der Qualität der Informationsversorgung wird erst durch das Zusammenspiel der genannten fachlichen, organisatorischen und technischen Maßnahmen erreicht. Die Erfahrungen mit EDW zeigen aber auch, dass vor allem die fachlichen und organisatorischen Aspekte oft "untergehen".

Welchen Nutzen bietet Enterprise Data Warehosuing?

Entwicklung, Umsetzung und Begleitung entsprechender Regeln sind als Investition zu verstehen. Der "Return" ist oft schwer quantifizierbar, ein EDW-Konzept bewirkt vielmehr qualitative Verbesserungen.

Qualität: Enterprise Data Warehousing sorgt dafür, dass Entscheider mit qualitativ hochwertigen und konsistenten Informationen (Kennzahlen, Berichte, ...) versorgt werden. Fragen und Probleme zur Datenqualität können schneller analysiert und geklärt werden.

Flexibilität: Indem neue Anforderungen zu einem gewissen Grad bereits vorgedacht werden (z.B. durch zusätzliche Felder im Extraktor) kann bei neuen Anwenderwünschen schneller reagiert werden.

Wartbarkeit: Die Business Intelligence-Lösung bleibt beherrschbar und damit wartbar. Ein EDW-Konzept ist damit auch eine Art Investitionsschutz für die BI-Lösung insgesamt.

Effizienz: Neue Anforderungen können schneller und damit kostengünstiger umgesetzt werden, Fragen der Datenqualität werden effizienter an einer Stelle zentral gelöst.

Welche Erfahrungen und "Lessons Learned” liegen vor?

Die Erfahrungen mit diesem Konzept lassen sich wie folgt zusammenfassen:
  • EDW von Beginn an implementieren: Die Entwicklung des EDW-Konzepts sollte als eigenes "kleines" Projekt verstanden werden, so dass Enterprise Data Warehousing gleich von Beginn an berücksichtigt wird. So hat ein Unternehmen im ersten Schritt im Rahmen eines Prototyps zunächst eine Lösung für das Vertriebscontrolling erstellt, um schnell einen ersten Erfolg vorzuweisen. Vor dem weiteren Rollout wurde dann aber auf eine EDW-Architektur umgestellt. Der Prototyp ließ sich in dieser frühen Phase dann noch "einfangen".
  • Quick-wins realisieren:Themen der IT Architektur lassen sich oft relativ schnell und mit überschaubarem Aufwand umsetzen. Der Werkzeugkasten ist in
  • EDW-Konzept individualisieren: Gelegentlich finden sich bei Mittelständlern Konzepte für IT-Architekturen wieder, die auffällig den EDW-Konzepten großer BI-Implementierungen ähneln. Was in großen Organisationen funktioniert, kann für kleinere und mittelgroße Unternehmen schnell in überbordender Bürokratie enden. Einige Unternehmen kopieren bspw. bei einer BW Implementierung alle InfoObjekte je Datenschicht in einen eigenen Namensraum. Diese Vorgehensweise mag in großen Organisationen sinnvoll sein, um Entwicklungsaktivitäten zu entkoppeln. Die IT-Mannschaft eines Mittelständlers kann dies aber kaum "stemmen". Enterprise Data Warehousing sollte also nicht "von der Stange" sein, sondern pragmatisch an die personellen und organisatorischen Gegebenheiten kleinerer und mittlerer Unternehmen angepasst werden.
  • Regelchecks automatisieren: So kann man z.B. im Fall einer SAP NetWeaver BW Implementierung mittels eines kleinen ABAP-Programms schnell prüfen, ob Namenskonventionen eingehalten werden.
  • Commitment des Managements einholen: Zu den "dickeren" Brettern, die gebohrt werden müssen, gehören dann meist die fachliche Aspekte. So ist die Erstellung eines unternehmenseinheitlichen Kennzahlenkatalogs in der Regel die mühsamste und schwierigste Aufgabe. In einem mittelständischen Unternehmen sollte dies im Auftrag und mit Unterstützung der Geschäftsleitung geschehen Prozess- und Organisationsaspekte sind ebenfalls schwieriger umzusetzen. Die Rolle eines Key-Users zu besetzen, erfordert, dass dafür auch der entsprechende Freiraum eingeräumt wird.
Fazit: Enterprise Data Warehousing zentralisiert die Kontrolle über die Welt der Management-Informationen. Die Investition in ein EDW-Konzept ist auch bei kleineren und mittleren BI-Lösungen eine wichtige Voraussetzung für nachhaltigen Erfolg. Ebenso wichtig ist die anschließende kontinuierliche Begleitung aller Entwicklungsprojekte, um die Umsetzung der Regeln des EDW-Konzepts sicher zu stellen.

Wenn Sie weitere Informationen wünschen oder Fragen haben wenden Sie sich an: bernd.schrader@its-people.de

top

Newsletter-Archiv