Projekt Data Warehousing. Ich habe grade mal wieder eine Abfuhr bei einer Bewerbung bekommen, die Hürde des Recruiters nicht geschafft. Da klang recht unverblümt ein freundlich verpacktes unqualifiziert heraus. Als Rentner sollte man doch das machen, was von einem erwartet wird: Zuhause rumsitzen und auf den Tod warten. Scheiß drauf und ein frühliches jetzt erst recht! Ich habe beruflich jahrelang von dem gelebt, was Entwickler so abliefern. Ich habe dabei viele Pferde kotzen gesehen!
Für mich selbst ist SAP BW auch deshalb faszinierend, weil es genau dort ansetzt, wo die in einem Unternehmen anfallenden Daten auf ein reportingfähiges Minimum reduziert und harmonisiert werden. Je höher die Stellung in der Krawattenhierarchie eines Unternehmens, desto höher der Abstraktionsgrad, desto höher die Anforderungen an die Datenbereitstellung. Data Warehousing mit SAP BW ist letztendlich Business, gepaart mit etwas Technik und einem hauch von Progammierung. Datenflüsse werden mit vorgegebenen Elementen modelliert. Das hat durchaus den Flair von Lego. Wichtig ist dabei eine Kenntnis der Datenquelle und dessen Datenbankaufbau plus der notwendigen Datenkonstellationen, die den gewünschten Informationsinhalt liefern. Um Daten erweitern zu können, besitzt ein Datenflus die Möglichkeit, Daten über ABAP zu ergänzen. Die Anforderungen an eine formale ABAP-Programmierung auf einem SAP BW kriege ich noch nach einer halben Dose Bier hin, nach der zweiten Dosenhälfte schlafe ich eh ein.
Um in das Thema einzusteigen eine nicht unerwartbare Alalogie: So ein Data Warehouse gleicht einem Lager, oder zumindest dem, was sich ein bekennender Logistiklaie, wie ich es bin, darunter vorstellt:
Da ist der Betreiber des Lagers. Er bestimmt den Zweck und den Inhalt des Lagers und dieses ist natürlich sowohl von der Branche als auch von seinen Prozessen abhängig. Sehe ich mir das Lager an, bringt der Branchenhintergrund durchaus Hinweise darauf, was gelagert wird. Ich komme aus meiner Sicht nicht daran vorbei, mir die Branche, in meinem Fall die Elektrizitätswirtschaft, anzusehen. Ein Logistiker hat da andere Anforderungen als ein Krämer oder ein Saftladen.
Betrachte ich die Prozesse fallen mir drei Ordnungskriterien ein:
- Ein funktionales Lager integriert in einer Facility, oder wie man das auch immer nennen möchte
- Ein organisatorisch eigenständiges Lager mit eigener Beschaffung, Lagerhaltung und Distribution
- Ein Zwischenlager, das einfach nur die Warenströme zwischen einzelnen Facilities abwickelt
SAP BW, genauer gesagt, der ABAP-Level dazu deckt das lokale Reporting ab und machte die alten Lösungen obsolet. Übertragen wäre das Fall 1.
Da ist das organisatorisch eigenständige Lager von Fall 2. Übertragen auf ein Warehouse ist das der von mir hier zugrunde gelegte Fall.
Da ist zunächst einmal die Datenbeschaffung. Die kann klassisch Organisiert sein, mit Bestellung der benötigten Daten beim Lieferer, Zusammenstellung der angeforderten Waren und Anlieferung an das Lager. Die Beschaffung kann aber auch so organisiert sein, das ich mir meinen Troley / meine Gewerbeschachtel / meinen LKW nehme und im Rahmen einer Vereinbarung zum Lieferer fahre, mir mein benötigtes Material einpacke und die Waren zu ihrem Lager transportiere. Im Falle eines DW wäre das die Datenbeschaffung.
Da ist der Einfluss des Gebäudes und des Lagersystems des Lagers. Es bestimmt, wie ich die Waren einlagere. Übertrage ich das auf mein DW, komme ich nicht um eine Betrachtung des Trägersystems (klassisches DBMS oder HANA) und der Versionshistorie herum.
Ein wesentlicher Punkt in einem Lager ist auch die Warenausgabe. Die angeforderten Daten müssen bereitgestellt werden, optimal wäre es, wenn bereits meine Warenablage auf sich wiederholende Prozesse optimiert ist. Die Distribution der Waren braucht sich nicht nur auf Endverbraucher beschränken, da kommen auch andere Lager oder weiterverarbeitende Betriebe in Frage. Im Falle eines DW wäre das eine Betrachtung des nachgeschalteten Reportings, entweder über Query oder Drittprodukte wie Business Objects.
Fall 3 in mein Aufstellung schenke ich mir an dieser Stelle erste einmal.
In meiner aktiven Zeit so ziemlich alle Versionen von SAP Business Warehouse bis einschl. Version 7.4 supported, für die Version 7.5 hatte ich noch eine Schulung bekommen. Das Ziel von SAP, das Data Warehouse zu vereinfachen zeichnete sich seit 7.2 oder 7.3 ab. Die Architektur von SAP HANA kommt der Problematik eines Data Warehouse mit seinen großen Datenmengen sehr weit entgegen.
Dieser Bereich hat für mich Projektcharakter. Es kann also durchaus sein, das Teile inkonsitient sind oder noch fehlen. Meine Kontrolle besteht darin, etwas eine weile Stehen zu lassen und es dann neu zu überdenken.