DE102004001835A1

DE102004001835A1 - Stammdaten-Verwaltungssystem für die zentrale Verwaltung von Kernreferenzdaten, die einem Unternehmen zugeordnet sind

Info

Publication number: DE102004001835A1
Application number: DE200410001835
Authority: DE
Inventors: Vasudev Arlington Rangadass
Original assignee: I2 Technologies Inc
Current assignee: Blue Yonder Group Inc
Priority date: 2003-01-13
Filing date: 2004-01-13
Publication date: 2004-07-22
Also published as: US9529886B2; US10042904B2; US20070192361A1; US7213037B2; US7765185B2; US20080052316A1; US20080052311A1; US9037535B2; US20150254321A1; US7725429B2; US8725678B2; US20080052310A1; US20140250057A1; US20040215655A1; US20040225677A1; US20040215662A1; US20170140015A1; US20040177075A1; TW200419413A; US8204922B2

Abstract

In einem Ausführungsbeispiel wird ein System für die zentrale Verwaltung von Kernunternehmensreferenzdaten, die einem Unternehmen zugeordnet sind, zur Verfügung gestellt. Ein zentralisiertes Stammdepot enthält die Kernunternehmensreferenzdaten. Ein internes Dienstegefüge, das mit dem zentralisierten Stammdepot verbunden ist, stellt interne Dienste zur Verwaltung der Kernunternehmensreferenzdaten im zentralisierten Stammdepot zur Verfügung, wobei einer oder mehrere der internen Dienste direkten Zugriff auf die zu Verwaltungszwecken im zentralisierten Stmmdepot gespeicherten Kernunternehmensreferenzdaten haben. Eine Infrastrukturdiensteebene, die mit dem zentralisierten Stammdepot verbunden ist, stellt Massendatentransfers von Kernunternehmensreferenzdaten zwischen dem zentralisierten Stammdepot und einem oder mehreren externen Betriebssystemen entsprechend einem oder mehreren Geschäftsabläufen auf Unternehmensebene zur Verfügung, wobei den externen Betriebssystemen indirekter Zugriff auf die Kernunternehmensreferenzdaten, die zu Betriebszwecken im zentralisierten Stammdepot gespeichert sind, gestattet ist.

Description

Diese Erfindung bezieht sich im Allgemeinen auf Unternehmensmanagement-Lösungen und im Besonderen auf ein Stammdaten-Verwaltungssystem, das für die zentrale Verwaltung von Kernreferenzdaten , die einem Unternehmen zugeordnet sind, verwendet wird.
Ein Unternehmen kann ein Datenverwaltungssystem verwenden, um Unternehmensdaten zu verwalten. Eine beträchtliche Datenmenge ist nötig, um ein Unternehmen angemessen zu definieren. Dabei können zwei grundlegende Datentypen auftreten. Ein erster Datentyp, der als Kernunternehmensreferenzdaten bezeichnet werden kann, beschreibt die Struktur und die Eigenschaften des Unternehmens und seiner Entitäten und ist weder transienter noch transaktioneller Natur. Dieser Datentyp kann mit den Stammdaten des Unternehmens in Zusammenhang gebracht und in einem Kernreferenzdatendepot gespeichert werden, obwohl solche Daten nicht auf den Datentyp beschränkt sind, der mit herkömmlichen Unternehmensstammdaten in Verbindung gebracht wird. Der effiziente Umgang mit diesen Daten ist ebenso entscheidend wie die ordentliche und prozessorientierte Verwaltung des Datenstatus. Die Verwendung dieser Daten ist im Allgemeinen nicht auf bestimmte Bereiche des Unternehmens beschränkt, vielmehr werden diese Daten gewöhnlich innerhalb des gesamten Unternehmens sowie von seinen Wertschöpfungspartnern verwendet. Beim zweiten Datentyp, der als Betriebsdaten bezeichnet werden kann, handelt es sich um transiente transaktionelle Daten, die die Planung, Ausführung, Überwachung und andere Unternehmenslösungskomponenten erforderlich sind. Dieser Datentyp wird gewöhnlich nicht im Kernreferenzdatendepot gespeichert; das Datenverwaltungssystem stellt für solche Daten ein Bereitstellungs- und Verteilungsnetzwerk zur Verfügung. Ein Problem, dem viele Unternehmen gegenüberstehen, ist es, ein System zu erstellen, das effektive und skalierbare Verwaltung, Vertrieb und Verwendung von Kernunternehmensreferenzdaten und transaktionellen Daten in einer Weise zur Verfügung stellt, die sowohl dem Bedarf dieser Daten innerhalb des Unternehmens als Ganzem als auch spezifischem Bedarf für Planung, Ausführung, Überwachung und andere Unternehmenslösungskomponenten im Zusammenhang mit dem Unternehmen gerecht wird.
In einem Ausführungsbeispiel wird ein System für die zentrale Verwaltung von Kernunternehmensreferenzdaten, die einem Unternehmen zugeordnet sind, zur Verfügung gestellt. Ein zentralisiertes Stammdepot enthält die Kernunternehmensreferenzdaten. Ein internes Dienstegefüge, das mit dem zentralisierten Stammdepot verbunden ist, stellt interne Dienste für die Verwaltung von Kernunternehmensreferenzdaten innerhalb des zentralisierten Stammdepots zur Verfügung, wobei einer oder mehrere der internen Dienste direkten Zugriff auf die Kernunternehmensreferenzdaten haben, die zu Verwaltungszwecken im zentralisierten Stammdepot gespeichert sind. Eine Infrastruktur-Diensteebene, die mit dem zentralisierten Stammdepot verbunden ist, stellt Massendatentransfers von Kernunternehmensreferenzdaten zwischen dem zentralisierten Stammdepot und einem oder mehreren externen Betriebssystemen entsprechend einem oder mehreren Geschäftsabläufen auf Unternehmensebene zur Verfügung, wobei den externen Betriebssystemen ein indirekter Zugriff auf die Kernunternehmensreferenzdaten gestattet ist, die im zentralisierten Stammdepot zu betrieblichen Zwecken gespeichert sind.
Einzelne Ausführungsformen der vorliegenden Erfindung können einen oder mehrere technische Vorteile zur Verfügung stellen. Bestimmte Ausführungsbeispiele können z.B. ein Unternehmensgefüge zur Verfügung stellen, in dem Klassifizierungen in Konfigurations-, Planungs-, Ausführungs- und Überwachungssegmente eingeschlossen sind. Bestimmte Ausführungsbeispiele können ein sicheres Aufzeichnungssystem, das in Architektur und Design für die Verwaltung von Kernunternehmensreferenzdaten optimiert ist, zur Verfügung stellen. Bestimmte Ausführungsbeispiele können die vollständige oder partielle Automatisierung von wichtigen zeit- und arbeitsintensiven Geschäftsprozessen gemäß eingebetteten Geschäftsabläufen auf Unternehmensebene erlauben. Bestimmte Ausführungsbeispiele können alle, einige oder keine dieser technischen Vorteile zur Verfügung stellen. Bestimmte Ausführungsbeispiele können einen oder mehrere andere technische Vorteile zur Verfügung stellen, von denen einer oder mehrere möglicherweise aus den nachstehend aufgeführten Abbildungen, Beschreibungen und Ansprüchen den Fachleuten sofort ersichtlich sind.
Zum vollständigeren Verständnis der vorliegenden Erfindung sowie ihrer Merkmale und Vorteile wird auf die folgende Beschreibung in Verbindung mit den begleitenden Zeichnungen verwiesen, in denen:
1 ein Beispiel eines Unternehmensanwendungsgefüges zeigt, das ein Stammdaten-Verwaltungssystem (MDM-System) enthält;
2 ein Beispiel einer logischen Geschäftsarchitektur auf hoher Ebene für ein MDM-System zeigt;
3 ein Beispiel einer logischen technischen Architektur auf hoher Ebene für ein MDM-System zeigt;
4 ein Beispiel einer logischen Datendienstarchitektur auf hoher Ebene für ein MDM-System zeigt;
5 ein Beispiel einer logischen Architektur auf hoher Ebene einer MDM-Datenbank zeigt;
6 ein Beispiel einer Infomationsverteilungsarchitektur für ein MDM-System zeigt;
7 ein Beispiel eines MDM-Studios und einer zugehörigen MDM-Modellbibliothek zeigt;
8 ein Beispiel eines MDM-Verwendungsmodells zeigt;
9 ein Beispiel einer physischen Architektur auf hoher Ebene für ein MDM-System zeigt; und
10 zeigt ein Beispiel eines Einführungsprozesses für neue Artikel innerhalb eines MDM-Systems.
I. Lösungsgefüge für Unternehmen
1 zeigt ein Beispiel eines Lösungsgefüges für Unternehmen 2, der ein MDM-System 4 enthält. In einem Ausführungsbeispiel enthält das Gefüge 2 eine Klassifikation eines zugeordneten Unternehmens in vier fundamentale Segmente: (1) Konfiguration des Unternehmens und seiner Entitäten; (2) Planung hinsichtlich des Unternehmens und seiner Entitäten; d.h. Entscheidungen darüber, was zu tun ist; (3) Ausführung hinsichtlich des Unternehmens und seiner Entitäten; d.h. nach diesen Entscheidungen handeln; und (4) Überwachung hinsichtlich des Unternehmens und seiner Entitäten; d.h. Überwachung der Ergebnisse dieser Entscheidungen und entsprechende Lieferung von Feedback an die Konfigurations- und Planungssegmente. In diesem Ausführungsbeispiel repräsentiert das MDM-System 4 das Konfigurationssegment, während die Unternehmenslösungskomponenten für die Planung, Ausführung und Überwachung 6 jeweils die Planungs-, Ausführungs- und Überwachungssegmente repräsentieren.
Das MDM-System 4 stellt die zentralisierte Speicherung und Verwaltung der Unternehmensreferenzdaten zur Verfügung, wobei die Referenzdaten und zugeordneten Datenverwaltungsprozesse von den Unternehmenslösungskomponenten 6 und zugeordneten Betriebsprozessen getrennt bleiben, während Referenzdaten für Unternehmenslösungskomponenten 6 zum Verbrauch nach Bedarf bereit gestellt werden. Die zentralisierte Speicherung und Verwaltung von Referenzdaten für existierende und zukünftige Unternehmenslösungskomponenten 6 kann die Erweiterung oder andere Modifikation von Unternehmenslösungskomponenten 6 ermöglichen, ohne dass Referenzdaten innerhalb des MDM-Systems 4 angepasst werden müssen. Die zentralisierte Speicherung und Verwaltung von Referenzdaten kann außerdem die Integration von Unternehmenslösungskomponenten 6 ermöglichen, z.B. wenn eine Unternehmenslösungskomponente 6 durch eine andere ersetzt wird oder eine Unternehmenslösungskomponente eingeführt wird, die eine komplett neue Geschäftsfunktion liefert. Die zentralisierte Speicherung und Verwaltung von Referenzdaten kann weiterhin die Integration von einem Unternehmen in ein anderes ermöglichen, z.B. im Zusammenhang mit einer Fusion oder Akquisition.
Infrastruktur-Dienste 8 stellen Massendatentransfers und Mitteilungsübermittlung im Unternehmen zwischen MDM-System 4 und Unternehmenslösungskomponenten 6 in Übereinstimmung mit Geschäftsabläufen zur Verfügung, die im Zusammenhang mit Infrastrukturdiensten 8 betrieben werden. Diese Abläufe, die teilweise in das MDM-System 4 und teilweise in die Infrastrukturdienste 8 eingebettet sein können, können angepasste beste Geschäftspraktiken des Unternehmens beinhalten. Zusätzlich können diese Abläufe ganz oder teilweise automatisiert sein und eine entsprechende Arbeitsablauf-Engine auf Unternehmensebene sowie entsprechende für diese Arbeitsablauf-Engine verfügbare MDM-Systemressourcen verwenden.
II. Logische MDM-Geschäftsarchitektur
2 zeigt ein Beispiel einer logischen Geschäftsarchitektur 10 auf hoher Ebene für ein MDM-System 4. Im Allgemeinen repräsentiert die logische Geschäftsarchitektur eine geschäftszentrierte Ansicht des MDM-Systems 4 und enthält Kerngeschäftsprozesse, Dienste und Datenelemente, sodass es sein kann, dass das MDM-System 4 – abhängig von der An des dem MDM-System 4 zugeordneten Unternehmens – diese zur Verfügung stellen muss. In einem Ausführungsbeispiel enthält das MDM-System 4 eine Prozessebene 12, die einen Kontext für die Einführung und vollständige oder partielle Automatisierung von Geschäftskonfigurationsprozessen 14 zur Verfügung stellt. Eine Dienstebene 16, die der Prozessebene 12 zugrunde liegt, stellt Dienste 18 zur Verfügung, welche Funktionen zur Verfügung stellen, die für Prozesse 14 geeignete Prozessaufgaben ermöglichen. Eine Datenebene 20, die der Dienstebene 16 zugrunde liegt, stellt Basis-Datenmodelle und physische Darstellungen zur Verfügung, die zum Speichern von Kernunternehmensreferenzdaten 22 zur Gewinnung und Verwendung im Zusammenhang mit Prozessen 14 und zugeordneten Diensten 18 verwendet werden.
Das Verständnis der grundlegenden Konzepte im Zusammenhang mit den Zwecken und den Funktionen des MDM-Systems 4 kann zum Verständnis der MDM-Architektur beitragen. Kern des MDM-Systems 4 ist das Konzept der Datenverwaltung, die umfasst, sowohl welche Daten gespeichert werden als auch wie die Daten gespeichert werden und einer Verwendung zugänglich gemacht werden. Da das MDM-System 4 sich primär mit den strukturellen Daten befasst, die das Unternehmen beschreiben, oder, präziser gesagt, mit Daten zu den Entitäten innerhalb der Geschäftsstruktur des Unternehmens zusammenhängen, liegt der Schwerpunkt der MDM-Architektur auf der Speicherung, Verwaltung und Gewinnung von Daten, die mit Entitäten oder Beziehungen zwischen Entitäten zusammenhängen. In einem Ausführungsbeispiel stellt das MDM-System 4 diese Speicherung, Verwaltung und Gewinnung von Daten unter Verwendung eines MDM-Kernreferenzdatendepots auf der Grundlage eines multidimensionalen Datenbankkonstrukts zur Verfügung.
Man stelle sich folgendes Beispiel vor. Ein Beispiel einer einem Einzelhandelsunternehmen zugeordneten Entität ist ein Artikel. Artikel können mit Attributen versehen sein, wie z.B. Größe, Gewicht, Farbe usw. Wenn eine bestimmte Entität, in diesem Fall ein bestimmter Artikel, als Koordinate in einer ersten Dimension betrachtet wird, die Artikel repräsentiert, dann werden die Attribute der bestimmten Artikelentität mit der Koordinate für den bestimmten Artikel in der Artikeldimension zugeordnet. An diesem Punkt betrifft das Beispiel nur einen eindimensionalen Linienraum, in dem diskrete Punkte auf der Linie bestimmte Artikel repräsentieren.
Ein weiteres Beispiel einer einem Unternehmen zugeordneten Entität ist ein Lager oder ein anderer Ort. Orte können über Attribute wie z.B. Größe, physische Adresse usw. verfügen. Wie die oben beschriebenen bestimmten Artikel, kann ein bestimmter Ort als Koordinate in einer zweiten Dimension betrachtet werden, die Orte repräsentiert, wobei die Attribute der bestimmten Ortsentität der Koordinate für den bestimmten Ort in der Ortsdimension zugeordnet sind. An diesem Punkt betrifft das Beispiel zwei eindimensionale Linienräume, in denen diskrete Punkte auf der ersten Linie bestimmte Artikel repräsentieren und diskrete Punkte auf der zweiten Linie bestimmte Orte repräsentieren. Das Beispiel kann erweitert werden, sodass es Attribute enthält, die von einer Kombination aus einem bestimmten Artikel und einem bestimmten Ort abhängen. Weder die Artikeldimension noch die Ortsdimension alleine reichen aus, um solche multidimensionalen Attribute zu speichern. Wenn jedoch die Artikel- und die Ortsdimensionen als Achsen gesehen werden und jeder Schnittpunkt von Artikel- und Ortskoordinaten innerhalb eines Raums, der durch eine orthogonale Anordnung dieser Achsen definiert wird, als ein Punkt (Artikel, Ort) in einem zweidimensionalen Entitätenraum gesehen werden, in dem solche Attribute gespeichert werden, wird das Konzept klar.
Das Beispiel kann weiterhin so ausgedehnt werden, dass es Attribute enthält, die von der Kombination aus einer beliebigen Anzahl von willkürlichen Entitätendimensionen abhängen, und so zum Konzept der Attribute als generelle Daten führen, die an Punkten in einem n-dimensionalen Entitätenraum gespeichert sind und von dort abgerufen werden. Zum Beispiel kann ein bestimmter dreidimensionaler Entitätenraum, der für ein Beispiel eines Einzelhandelunternehmens geeignet ist, Artikel-, Orts- und Zeitdimensionen enthalten, in denen die an jedem Punkt (Artikel, Ort, Zeit) gespeicherten Attribute innerhalb eines von einer rechtwinkligen Anordnung dieser Achsen bestimmten Umfangs einer bestimmtem Kombination von Entitäten in den Artikel-, Orts- und Zeitdimensionen entsprechen. In einem Ausführungsbeispiel können alle Referenzdaten 22, die innerhalb des MDM-Systems 4 gespeichert sind, zu einem Attribut äquivalent sein, das einem Punkt in einem n-dimensionalen Entitätenraum zugeordnet ist.
In einem Ausführungsbeispiel ist eine vorrangige Eigenschaft aller Daten, die für die Aufnahme in das MDM-System 4 in Betracht gezogen werden, das oben beschriebene multidimensionale Datenbankkonstrukt. Demzufolge kann es ein architektonisches Kernprinzip des MDM-Systems 4 sein, eine dimensionale Datenstruktur als ein Kernelement in jeder Komponente des MDM-Systems 4 anzupassen. Dies kann einige wichtige Auswirkungen auf die MDM-Architektur und ihre Anordnung haben. Darunter fallen z.B. ohne Einschränkung die folgenden wichtigen Auswirkungen: (1) ein konsistenter Mechanismus zum Auffinden von Punkten in einem n-dimensionalen Entitätenraum; (2) ein konsistenter Mechanismus zum Speichern von Daten in und zum Abrufen von Daten aus einem n-dimensionalen Entitätenraum; und (3) gewährleisten, dass alle bestimmten Datenspeicherkomponenten die oben genannten Punkte unterstützen.
Ein weiteres grundlegendes Konzept für das MDM-System 4 kann die Optimierung der physischen Architektur- und Datenbankstrukturen für die gewünschten Funktionen des MDM-Systems 4 betreffen. Das MDM-Kernreferenzdatendepot dient, wie oben beschrieben, primär der Datenverwaltung und ist so strukturiert, dass es einen umfassendes Gefüge für die Datenverwaltung zur Verfügung stellt. Auf der anderen Seite kann für die Elemente des MDM-Systems 4 für Datenbereitstellung und -verteilung bei Ein- und Ausgang ein effizienter Datentransfer und Durchsatz erforderlich sein. Während viele Systeme versucht haben, mit ihrer Architektur einen Kompromiss zur Verfügung zu stellen, der allen solchen Anforderungen gerecht wird, ist das MDM-System 4 vorzugsweise dahingehend strukturiert, dass jedes Element daraufhin ausgerichtet ist, seine jeweiligen Funktionen optimal zu erfüllen.
Das MDM-System 4 kann für Unternehmen in unterschiedlichen Szenarien wertvoll sein, wie z.B. Einzelhandel, Fertigung oder andere Szenarien. Obwohl zur Darstellung Beispiele aus dem Einzelhandelsbereich gewählt wurden, geht die vorliegende Erfindung davon aus, dass das MDM-System 4 in Verbindung mit jedem geeigneten Unternehmen verwendet und auf dieses zugeschnitten werden kann. Die MDM-Architektur und -Anordnung sind vorzugsweise dahingehend konstruiert, Elemente zur Verfügung zu stellen, die dazu geeignet sind, eine erfolgreiche Umsetzung des MDM-Systems 4 in einer Vielzahl von Branchen und einer Vielzahl von Unternehmen innerhalb einer bestimmten Branche zu erlauben.
A. Prozessebene
Wie oben beschrieben, enthält das MDM-System 4 eine Prozessebene 12, die den Kontext für die Umsetzung und vollständige oder partielle Automatisierung von Geschäftskonfigurationsprozessen 14 zur Verfügung stellt. Im Allgemeinen stellen Prozesse 14 Funktionen zur Verfügung, die nötig sind, um Prozessabläufe zu realisieren, die als Teil einer MDM-Lösung zur Verfügung gestellt werden, wobei Struktur für Unternehmensaktivitäten zur Verfügung gestellt wird und diese Aktivitäten in die Lage versetzt werden, von Zeit zu Zeit wiederholt, kontrolliert, überwacht und verbessert zu werden. Jeder Prozess 14 repräsentiert eine Sequenz von Aufgaben, die zusammen eine Geschäftsaktivität bilden. Das MDM-System 4 kann native Unterstützung für generische Prozesse 14 und spezifische Unterstützung für bestimmte Prozesse 14 zur Verfügung stellen. In einem Ausführungsbeispiel erlauben die Prozesse 14, dass umfassende Geschäftsabläufe in das MDM-System 4 eingebettet werden und dass diese unter Verwendung von Ressourcen in den darunter liegenden Dienst- und Datenebenen 16 bzw. 20 unterstützt werden. In einem Ausführungsbeispiel stellt das MDM-System 4 für die Umsetzung und die vollständige oder partielle Automatisierung aller entsprechenden Prozesse 14 eine hoch konfigurierbare, flexible und erweiterbare Umgebung zur Verfügung.
Prozesse 14 können auf zwei Ebenen operieren. Die erste Ebene, die Unternehmensebene, kann umfangreichere Prozesse 14 innerhalb von und zwischen Unternehmen enthalten, die mit der Verwaltung von Daten in Verbindung stehen, soweit sie sich auf die anvisierten Zielen der MDM-Lösung beziehen. So ist z.B., wenn das MDM-System 4 einem Einzelhandelsunternehmen zugeordnet ist, ein Prozess 14 zur Einführung eines neuen Artikels, der auch das Speichern von extern erstellten Daten über den neuen Artikel im MDM-Kernreferenzdatendepot umfasst, ein Beispiel für einen Prozess 14 der ersten Ebene. Die zweite Ebene kann weniger umfangreiche Verwaltungsprozesse 14 enthalten, die die Übertragung von Daten innerhalb des MDM-Systems 4 betreffen, wie z.B. das Abrufen von Daten aus MDM-Kernreferenzdatendepots in Übereinstimmung mit Anfragen von Benutzeroberflächen, Analysen oder anderen Diensten innerhalb des MDM-Systems 4.
So können generische Prozesse 14, die auf jedes Unternehmen und jede Dimension des MDM-Systems 4 angewendet werden können, zum Beispiel ohne Einschränkung enthalten: (1) Einführung neuer Entitäten; (2) Wartung von Entitäten; (3) Neuordnung von Metadaten; (4) Entnahme von Entitäten; und (5) Nachbildung von Entitäten.
1. Einführung neuer Entitäten
Dieser Prozess 14 repräsentiert die Einführung einer neuen Entität in das MDM-System 4. Im Fall eines Beispielhaften Einzelhandelsunternehmens kann dies die Einführung eines neuen Artikels, Ortes, Verkäufers oder Kunden enthalten. Der Prozess 14 kann durch das Unternehmen ausgelöst werden, das dem MDM-System 4 zugeordnet ist, oder durch jedes andere Unternehmen, wie z.B. die Einführung eines Verkäufers eines neuen Artikels. Ein Verkäufer, der einen neuen Artikel zur Verfügung stellt, kann als ein Beispiel für Inhaltsaustausch betrachtet werden. In jedem Fall muss das Einzelhandelsunternehmen, das dem MDM-System 4 zugeordnet ist, dem MDM-System 4 unternehmensspezifische Daten für den neuen Artikel hinzufügen, die Daten bestätigen, der Verwendung des neuen Artikels zustimmen und den neuen Artikel als für die Verwendung in Planung, Ausführung, Überwachung und anderen Unternehmenslösungskomponenten 6 gegebenenfalls durch Nachbildung zugänglich veröffentlichen. Ein Beispiel für den Prozess 14 für die Einführung eines neuen Artikels wird weiter unten ausführlich in Zusammenhang mit 10 beschrieben.
2. Wartung von Entitäten
Dieser Prozess 14 betrifft Aktualisierung von einer oder mehreren Eigenschaften einer vorhandenen Entität, wie z.B. einem Artikel, Ort, Verkäufer oder Kunden für ein beispielhaftes Einzelhandelsunternehmen. Der Prozess 14 kann durch das Unternehmen ausgelöst werden, das dem MDM-System 4 zugeordnet ist, oder durch jedes andere Unternehmen, wie z.B. einem Verkäufer eines Artikels, für den eine oder mehrere Eigenschaften aktualisiert werden sollen. So kann z.B. ein „verbesserter" Artikel seine ursprüngliche Teilenummer und Lagereinheit beibehalten, der Verkäufer kann jedoch eines oder mehrere der primären Attribute, wie z.B. Größe, Gewicht oder Farbe, ändern. Gleichermaßen kann das Einzelhandelsunternehmen eines oder mehrere sekundäre Attribute eines vorhandenen Artikels ändern.
3. Neuordnung von Metadaten
Dieser Prozess 14 betrifft Übertragung innerhalb einer Dimension eines oder mehrerer Mitglieder einer Ebenenbeziehung in eine andere Ebenenbeziehung in einer dimensionalen Hierarchie. So kann z.B. ein Einzelhandelsunternehmen einen Artikel von einer Klasse in eine andere übertragen, wofür dann wiederum die Identifikation von dem einem oder den mehreren Mitgliedern erforderlich wäre, damit die Zielbeziehungen geändert werden können. Der Prozess 14 erfordert möglicherweise die Einhaltung entsprechender Prüfprozesse, und bei der Kassenbuchprüfung sind möglicherweise ein oder mehrere Unterprozesse für die Genehmigung erforderlich.
4. Entnahme von Entitäten
Dieser Prozess 14 betrifft Bereitstellung von Auswahlkriterien für eine oder mehrere Entitäten, Durchführung einer entsprechenden Abfrage und Übertragen von entsprechenden Daten oder eine andere An der Verfügungsstellung von Daten für die anfragende Rolle oder das anfragende Untersystem.
5. Nachbildung von Entitäten
Dieser Prozess 14 betrifft vollständige oder teilweise systematische Nachbildung von Daten im MDM-System 4 auf andere Untersysteme zur internen Verwendung. Eine solche Nachbildung erlaubt eine Nutzung der Daten in effizienterer Weise als durch den direkten operativen Zugriff auf das MDM-Kernreferenzdatendepot.
B. Dienstebene
Wie oben beschrieben, stellt die Dienstebene 16 Dienste 18 zur Verfügung, die Funktionen zur Verfügung stellen, die die Konstruktion von für Prozesse 14 geeigneten Prozessaufgaben ermöglichen. Jeder Dienst 18 stellt eine nützliche Arbeitseinheit zur Verfügung oder ermöglicht eine Prozessaufgabe im Kontext des MDM-Systems 4. Dienste 18 sind keine Prozesse 14; vielmehr ist ein Dienst 18 analog zu einer Aufgabe innerhalb eines Prozesses 14 oder einer Aktion als Antwort auf eine Anfrage, die einem Prozess 14 zugeordnet ist, wie z.B. Berechnung des Wertes einer Funktion, die dem Dienst 18 zugeordnet ist, oder Ausgabe einer Anfrage zum Anzeigen, Aktualisieren oder Löschen von Informationen im MDM-Kernreferenzdatendepot. In einem Ausführungsbeispiel können Dienste 18 innerhalb einer Dienstebene 16 des MDM-Systems 4 für ein beispielhaftes Einzelhandelsunternehmen ohne Einschränkung enthalten: (1) Entitätenwartungsdienste 18a; (2) Metadatenwartungsdienste 18b; (3) Parameterwartungsdienste 18c; (4) Attribut-/Eigenschaftsdienste 18d; (5) Ereignis(Kalender-)Dienste 18e; (6) Lieferkettennetzwerkdienste 18f; (7) Beschaffungsdienste 18g; (8) aktivitätsbasierte Kostendienste (ABC) 18h; (9) Vertragsdienste 18i; und (10) Stücklistendienste (BOM) 18j.
1. Entitätenwartung
Entitätenwartungsdienste 18a stellen grundlegende Funktionen zum navigieren, filteren und sortieren von Entitäten innerhalb des MDM-Systems 4 zur Verfügung. Im Fall eines beispielhaften Einzelhandelsunternehmens sind Artikel, Orte, Verkäufer und Kunden Entitätentypen, die innerhalb des MDM-Systems 4 verwaltet und unter Verwendung von Entitätenwartungsdiensten 18a gewartet werden.
2. Metadatenwartung
Metadatenwartungsdienste 18b stellen grundlegende Funktionen für die Konstruktion, Verwaltung und Neuordnung von entsprechenden Metadaten zur Verfügung. Solche Metadaten können beispielsweise Metadaten beinhalten, die das Unternehmen als Ganzes, die Struktur des MDM-Systems 4, die Strukturen von Bereichen zur Datenbereitstellung innerhalb des MDM-Systems 4 und die Beziehungen zwischen den Bereichen und dem MDM-Kernreferenzdatendepot beschreiben. Solche Funktionen können die Fähigkeit enthalten, Dimensionen zu erzeugen und Hierarchien in den Dimensionsräumen zu definieren, wobei jede Hierarchie eine Anzahl von Ebenen enthält, von denen jede über eine Anzahl von Mitgliedern verfügt. Solche Funktionen können auch Wartung hinsichtlich Dimensionen, Ebenen und Mitgliedern enthalten, wie z.B. Erstellen, Bearbeiten oder Löschen von solchen Metadatenelementen.
3. Parameterwartung
Parameterwartungsdienste 18c stellen grundlegende Funktionen für die Wartung, Verwaltung und Vertrieb von Unternehmenslösungskomponentenparametern (d.h. Geschäftsregelparameter) zur Verfügung. Ein oder mehrere Parameter können spezifisch für eine oder mehrere bestimmte Unternehmenslösungskomponenten 6 sein, müssen dies jedoch nicht. Jeder Parameter kann an eine oder mehrere Entitäten gebunden sein und in diesem Fall als ein zweites Attribut der Entitäten gesehen werden (im Gegensatz zu primären Attributen, wie z.B. Größe, Gewicht und Farbe eines Beispielartikels). Parameterwartungsdienste 18c stellen Funktionen zur Verfügung, die besonders für diese Typen von Attributen geeignet sind. Das MDM-System 4 kann nicht nur Speicherung solcher Attribute und Abrufen solcher Attribute zur Verwendung zur Verfügung stellen, sondern kann auch ein standardisiertes Verwaltungsparadigma für alle Parameter in der gesamten Unternehmenslösung zur Verfügung stellen. In einem Ausführungsbeispiel hat dies den zuträglichen Effekt, dass eine einheitliche Methodologie für die Parameterverwaltung zur Verfügung gestellt wird und dass Punktlösungskomponenten nicht diese Funktionalität zur Verfügung stellen müssen.
4. Attribut-/Eigenschaftsdienste
Einige Attribute von Entitäten sind quantitativ, gut definiert und zeitlich stabil. Beispiele für solche Attribute können Größe, Gewicht und Farbe eines Artikels oder die Adresse eines Verkäufers einbeziehen. Andere Arten von Attributen sind eher qualitativ, weniger gut definiert und können sich mit der Zeit ändern. Diese Attribute, die auch als Eigenschaften bezeichnet werden können, sind oft nützlich für kundenzentriertes Marketing und dienen als Basis für die Erstellung von Attribut-/Eigenschaftsgruppen. Attribut-/Eigenschaftsdienste 18d stellen Funktionen zur Verfügung, die für diese Art von Daten geeignet sind, die sich innerhalb des MDM-Systems 4 befinden oder mit einem MDM-System 4 verwaltet werden. Da die Anzahl und sogar die Arten solcher Attribute/Eigenschaften gewöhnlich nicht a priori bekannt sind, sind die Anforderungen an die physische Struktur eines Systems zur Verarbeitung dieses Datentyps bis zu einem gewissen Grad anders als die für statischere Stammdaten. Attribut-/Eigenschaftsdienste 18d stellen grundlegende Funktionen zur Erzeugung, Wartung und Verwendung dieses Datentyps zur Verfügung und können außerdem anspruchsvollere Dienste, wie z.B. Dienste zur Attribut-/Eigenschafts-gruppierung, enthalten.
5. Ereignis-(Kalender-)Dienste
Ereignis- oder genereller Kalenderdienste 18e beschäftigen sich mit der Verwaltung von zeitbedingten Aktivitäten. Diese Dienste 18e stellen grundlegende Funktionen zur Erzeugung von Referenzkalendern und zur Erzeugung und Verwaltung von zeitbedingten Aktivitäten (d.h. Ereignisse mit Bezug auf etablierte Kalender) zur Verfügung.
6. Lieferkettennetzwerkdienste
Lieferkettennetzwerkdienste 18f stellen grundlegende Funktionen zur Unterstützung der Definition und Verwendung des physischen Lieferkettennetzwerkes in Zusammenhang mit einem Unternehmen zur Verfügung. Das Lieferkettennetzwerk ist ausschlaggebend für viele Unternehmenslösungskomponenten 6 in der Planung, Ausführung, Überwachung usw., die durch die Verwendung des MDM-Systems 4 unterstützt werden.
7. Beschaffungsdienste
Beschaffungsdienste 18g stellen grundlegende Funktionen für Zugriff auf und Verwendung von Elementen des MDM-Modells zur Verfügung, wobei diese Elemente für Beschaffungslösungskomponenten relevant sind, wie z.B. eine Lösungskomponente für die Verwaltung der Lieferantenbeziehung,.
8. Aktivitätsbasierte Kostendienste (ABC)
Eine Vielzahl nützlicher Maßnahmen kann Entitäten zugeordnet werden, wie z.B. Artikel, bei denen das MDM-System 4 einem Einzelhandelsunternehmen zugeordnet ist, die bisher noch nicht einem Artikelkatalog oder einem ähnlichen Konstrukt zugeordnet sind. Diese Maßnahmen können nützliche erweiterte Analysen ermöglichen. Ein Beispiel sind Kosten- und Preisdaten, die Artikeln zugeordnet sind. Solche Daten können für erweiterte Preisbildungsoptimierung und ABC-Analysen verwendet werden. In einem Ausführungsbeispiel stellt das MDM-System 4 Modelle zum Erfassen von Kostendaten zur Verfügung, wie z.B. Kostenelemente, die, wenn aggregiert, die Gesamtkosten von Waren darstellen. Diese Modelle schließen Kosten, die Aktivitäten, wie z.B. Handhabung eines Artikels, während er die Punkte des zugeordneten Lieferkettennetzwerkes durchläuft, zugeordnet sind, ein. ABC-Dienste 18h stellen grundlegende Funktionen zur Handhabung von ABC-Daten zur Verfügung, die innerhalb des MDM-Systems 4 gespeichert sind und unter Verwendung eines MDM-System 4 verwaltet werden. Darüber hinaus sind Daten, wie z.B. normierte Nachfrageprofile (oder Zuordnungen zu solchen Profilen), Beispiele für sekundäre Attribute, die möglicherweise in das MDM-System 4 aufgenommen werden müssen.
9. Vertragsdienste
In einem Ausführungsbeispiel erstellt oder verwaltet das MDM-System 4 nicht unmittelbar Verträge für ein Beispielhaftes Einzelhandelsunternehmens . Jedoch stellt das MDM-System 4 vorzugsweise ein Depot für Vertragsdaten, die sich auf Entitäten beziehen, die innerhalb des MDM-System 4 gespeichert sind, und einen zentralisierten Vertriebsmechanismus für Vertragsdaten für entsprechende Unternehmenslösungskomponenten 6 zur Verfügung. Vertragsdienste 18i stellen grundlegende Funktionen für Eingang, Zuordnung und Vertrieb von vertragsbezogenen Daten zur Verfügung, die sich auf Kernunternehmensdaten beziehen, die innerhalb des MDM-Systems 4 liegen.
10. Stücklistendienste (BOM)
Für ein Beispielhaftes Einzelhandelsunternehmens stellen BPM-Dienste 18j grundlegende Funktionen für Erstellung, Verwaltung und Visualisierung von BOMs für das Unternehmen zur Verfügung. So kann z.B. ein einzelner tatsächlicher BOM zu gering für Planungszwecke sein, so dass ein geeigneter Verbund von einem oder mehreren tatsächlichen BOMs in einer entsprechenden Planungsrepräsentation erforderlich sein kann, um ein dem MDM-System 4 zugeordnetes Planungssystem zu unterstützen. Das MDM-System 4 kann solche Repräsentationen als Referenzdaten speichern und sie für die Planung und andere externe Betriebssysteme je nach Bedarf zur Verfügung stellen. Das MDM-System 4 kann außerdem basierend auf einem MDM-BOM-Modell automatisch solche Repräsentationen erstellen, um die Anforderung für die Auswertung und den Verbund einzelner tatsächlicher BOMs von Hand bei der Erstellung solcher Repräsentationen zu reduzieren oder eliminieren. BOM-Dienste 18j unterstützen vorzugsweise die Elemente jedes beliebigen geeigneten MDM-BOM-Modells.
C. Datenebene
Das MDM-System 4 beschäftigt sich grundlegend mit der Fähigkeit, Daten, die mit der Unternehmenslösung in Verbindung stehen, zu erzeugen, zu manipulieren und zu extrahieren. Wie oben beschrieben, stellt die Datenebene 20 die grundlegenden Datenmodelle und physischen Repräsentationen zum Speichern von unterschiedlichen Arten von Unternehmensreferenzdaten 22 zur Gewinnung und Verwendung im Zusammenhang mit Prozessen 14 und zugeordneten Diensten 18 zur Verfügung. In einem Ausführungsbeispiel können Referenzdaten 22 innerhalb der Datenebene 20 des MDM-Systems 4 für ein beispielhaftes Einzelhandelsunternehmens z.B. ohne Einschränkung enthalten: (1) Stammdaten 22a; (2) Metadaten 22b; (3) Unternehmensmodelle 22c; (4) Parameterdaten 22d; (5) Attribut-/Eigenschaftsdaten 22e; (6) Ereignis-(Kalender-)Daten 22f (7) Lieferkettennetzwerkdaten 22g; und (8) ABC-Daten 22h.

1. Stammdaten Stammdaten 22a repräsentieren Kernkonfigurationsdaten im Zusammenhang mit Entitäten, wie z.B. Artikel, Orte, Verkäufer und Kunden für ein beispielhaftes Einzelhandelsunternehmens . Viele Aspekte des Wertketten-Managements im Allgemeinen und insbesondere die meisten der Unternehmenslösungskomponenten 6 für Planung, Ausführung, Überwachung usw. im Besonderen erfordern Referenzdaten 22 hinsichtlich welche Artikel verkauft werden, welche Orte verkaufen die Artikel, welche Verkäufer liefern die Artikel, welche Kunden erwerben die Artikel und anderer grundlegender Datenelemente, auf denen alle anderen Unternehmensdaten ausbauen oder auf die sich alle anderen Unternehmensdaten in irgendeiner Weise beziehen. Das MDM-System 4 kann das herkömmliche Konzept von Stammdaten hinsichtlich solcher Entitäten erweitern und so komplexe Geschäftsabläufe erfassen, die für eine Unternehmenslösung vorgesehen sind. Obwohl bereits vorhandene Stammdaten, wie z.B. Artikel-Stammdaten, Attribute solcher Artikel wie z.B. Lagereinheiten (SKUs) erfassen können, die angeben, wo die Artikel sich in die hierarchische Struktur der Unternehmensdaten einfügen, gibt es keine Garantie dafür, dass ein bereits vorhandenes System solche Daten in einem dimensionalen Sinn manipulieren oder sogar sichten könnte. In einem Ausführungsbeispiel können ein Artikel oder andere Stammdaten für das MDM-System 4 Daten auf dimensionale Weise erstellen, manipulieren, navigieren, sichten und extrahieren. In einem Ausführungsbeispiel repräsentiert eine Entität innerhalb eines Stammdatentyps ein atomares Mitglied dieses Typs, wie z.B. einen bestimmten Artikel, einen bestimmten Ort, einen bestimmten Verkäufer oder einen bestimmten Kunden. Attribute von Entitäten, wie z.B. Artikel, Orte oder ähnliche, können wichtige Rollen hinsichtlich Unternehmenslösungskomponenten 6 für Planung, Ausführung, Überwachung usw. innehaben. Ein erster Typ eines Entitätenattributs ist ein physisches oder primäres Attribut, das im Allgemeinen mit inhärenten Eigenschaften der Entität, wie z.B. Größe, Gewicht und Farbe einer Beispiel-Artikelentität, in Zusammenhang steht. Primäre Attribute können z.B. bei der Planung eines Produktsortiments oder beim Lösen von logistischen Problemen, die mit dem Versand eines Auftrags für einen Artikel zusammenhängen, sehr wichtig sein. Primäre Attribute sind angemessen statisch und erfordern keinen anderen Bedeutungskontext als die zugeordnete Entität selbst. Ein zweiter Typ eines Entitätenattributs existiert als Folge der Verwendung der Entität innerhalb des Unternehmens, was zu einer definierten Beziehung zwischen der Entität und einer anderen Entität oder einem externen Maß führen kann. Ein Beispiel eines solchen Artikelattributs kann die Kategorie oder Unterkategorie innerhalb des Unternehmens sein, der der Artikel zugeordnet ist. Dieser Attributtyp, der oft als qualitatives oder sekundäres Attribut bezeichnet wird, kann für erweiterte Analysemethoden, wie z.B. Gruppierung von Artikeln, kundenorientiertes Marketing und Werbung, äußerst wichtig sein. In einem Ausführungsbeispiel erlauben die Stammdaten 22 die Verwaltung sowohl der primären als auch der sekundären Entitätenattribute durch das MDM-System 4. Es kann wichtig sein, zwischen Daten, die als Stammdaten 22a, und Daten, die als Attribut-/Eigenschaftsreferenzdaten 22e angesehen werden, wie sie unten beschrieben werden, zu unterscheiden. Wie oben erwähnt, können Stammdaten 22a angemessen statisch sein und sich möglicherweise im Laufe der Zeit nicht schnell ändern. So ändert sich z.B. eine Farbe (primäres Attribut) eines bestimmten Hemds innerhalb der Saison, in der dieses verkauft wird, möglicherweise nicht. Obwohl sich die Unterkategorie innerhalb des Unternehmens, der das Hemd zugeordnet ist (sekundäres Attribut), ändern kann, beispielsweise als Ergebnis einer Neuzuordnung, sind solche Änderungen äußerst unwahrscheinlich. Im Gegensatz dazu können z.B. Attribut-/Eigenschaftsdaten 22e häufig für das Zielsortiment verwendet werden und müssen somit auf dynamisches Verhalten von Kunden reagieren können. Zusätzlich können sich Attribute/Eigenschaften selbst ändern, wobei gegebenenfalls neue Attribute/Eigenschaften hinzugefügt werden und bereits vorhandene Attribute/Eigenschaften, die nicht mehr gültig sind, gegebenenfalls wegfallen.
2. Metadaten Eine andere An von Referenzdaten 22, die den oben beschriebenen Entitätenstammdaten eigen und für viele Unternehmenslösungskomponenten 6 sehr wichtig sind, sind Unternehmensmetadaten 22b. Im Allgemeinen sind Metadaten 22b Daten, die andere Daten beschreiben. Im Kontext des MDM-Systems 4 beschreiben Metadaten 22b die Struktur der Daten, die in einem MDM-System 4 gespeichert sind und mit dessen Hilfe verwaltet werden. Im Allgemeinen stellen Metadaten 22b eine Beschreibung der Struktur der dimensionalen Ansicht der Stammdaten 22a zur Verfügung. Der Schwerpunkt dieser Beschreibung liegt darauf welche Dimensionen vorhanden sind, welche Ebenen, beschreiben die Dimensionskoordinaten, und welche Mitglieder sind vorhanden und den Ebenen zugeordnet. Zusätzlich können Navigationskonstrukte, so genannte Hierarchien, definiert werden. Beispielsweise können in einem beispielhaftes Einzelhandelsunternehmens Metadaten 22b die unterschiedlichen Ebenen der Artikeltaxonomie sowie eine oder mehrere Hierarchien für die Navigation durch die unterschiedlichen Ebenen der Taxonomie enthalten. In einem Ausführungsbeispiel nimmt das MDM-System 4 Metadaten 22b in einer Form auf, die effektiv auf nachgelagerte Unternehmenslösungskomponenten 6 repliziert werden kann, die Konsistenz in der dimensionalen Ansicht der Stammdaten 22a erfordern. Wie oben im Zusammenhang mit den Metadatenwartungsdiensten 18b beschrieben, kann das MDM-System 4 die Erzeugen, Manipulation und Löschung von Metadaten 22b verwalten und die Neuzuordnung von Stammdaten 22a zur Verfügung stellen (z.B. Verschieben eines Artikels von einer ersten Kategorie in eine zweite Kategorie), so dass jede Neuzuordnung in den Metadaten 22b angemessen widergespiegelt wird.
3. Unternehmensmodelle Unternehmensmodelle 22c repräsentieren organisatorische Übersichten über die Rollen innerhalb eines Unternehmens. In einem Ausführungsbeispiel können sich die Unternehmensmodelle 22c über die Unternehmensgrenze hinaus erstrecken, um alle organisatorischen Elemente der dem Unternehmen zugeordneten Wertschöpfungskette abzudecken. Unternehmensmodelle 22c können hinsichtlich Authentifizierung und Autorisierung des Datenzugriffs wichtig sein. Zusätzlich können Unternehmensmodelle 22c Zustimmungsketten-Beziehungen liefern, die für die Geschäftsprozessverwaltung wichtig sind.
4. Parameterdaten
5. Attribut-/Eigenschaftsdaten
6. Ereignis-(Kalender-)Daten
7. Lieferkettennetzwerkdaten
8. Aktivitätsbasierte Kostendaten (ABC)

III. Logische technische MDM-Architektur
3 zeigt ein Beispiel einer logischen technischen Architektur 30 auf hoher Ebene für das MDM-System 4. Im Allgemeinen repräsentiert eine logische technische Architektur 30 eine technologiezentrierte Ansicht des MDM-Systems 4 und spezifiziert logische Elemente des MDM-Systems 4, die zusammen betrieben werden können, um die gewünschte MDM-Lösung zur Verfügung zu stellen. In einem Ausführungsbeispiel enthält eine logische technische Architektur 30 einen MDM-Dienstegefüge 32, der MDM-Kerndienste 34 enthält. Die MDM-Datenbank 36 enthält das MDM-Kernreferenzdatendepot. Bestimmte Dienste 34 können auf jede Klasse von Referenzdaten 22 angewendet werden, um innerhalb des MDM-Kernreferenzdatendepots angepasst zu werden. Andere Dienste 34 können auf bestimmte Klassen von Referenzdaten 22 zugeschnitten werden, die innerhalb des MDM-Kernreferenzdatendepots angepasst werden. Andere Dienste 34 können allgemein verschiedene Anforderungen an Sicherheitsstufen, Datenzugriff, Datenbereitstellung und andere Anforderungen an die Datenverwaltung unterstützen. Beispieldienste 34 werden weiter unten detaillierter beschrieben. Geeignete Dienste 34 können unter Verwendung eines oder mehrerer entsprechender Datenzugriffslinks 38 auf die Datenbank 36 zugreifen.
Externe Betriebssysteme 40 können unter Verwendung einer oder mehrerer Datenzugriffsebenen 42 Zugriff auf die Datenbank 36 haben. In einem Ausführungsbeispiel kann ein externes Betriebssystem 40 in Verbindung mit einem Geschäftsablauf unter Verwendung einer Front-Side Datenzugriffsebene 42a, eines zugeordneten Front-Bus 44a zwischen dem externen Betriebssystem 40 und der Front-Side Datenzugriffsebene 42a sowie einer zugeordneten Datenschnittstelle 46a zwischen der Front-Side Datenzugriffsebene 42a und der Datenbank 36 auf die Datenbank 36 zugreifen. Die Front-Side Datenzugriffsebene 42a wird üblicherweise verwendet, um Kontrolldaten zur Kontrolle von MDM-Vorgängen von externen Betriebssystemen 40 an das MDM-System 4 zu senden, und kann der Anwendungsintegration zugeordnet werden.
Einer oder mehrere Dienste 34 können unter Verwendung eines oder mehrerer entsprechender Datenzugriffslinks 48 Zugriff auf die Front-Side Datenzugriffsebene 42a haben. Ein externes Betriebssystem 40 kann unter Verwendung einer „Back-Side" Datenzugriffsebene 42b, eines zugeordneten „Back" -Bus 44b zwischen dem externe Betriebssystem 40 und der Back-Side Datenzugriffsebene 42b sowie einer zugeordneten Datenschnittstelle 46b zwischen der Back-Side Datenzugriffsebene 42b und der Datenbank 36 auf die Datenbank 36 zugreifen. Die Back-Side Datenzugriffsebene 42b wird üblicherweise für die Weiterleitung von Referenzdaten 22 zu und von externen Betriebssystemen 40 verwendet und kann der Datenintegration zugeordnet werden. Die Front-Side Datenzugriffsebene 42a kann jedoch, sofern angemessen, auch dazu verwendet werden, Referenzdaten 22 zu und von externen Betriebssystemen 40 zu übertragen, wenn z.B. ein externes Betriebssystem 40 in einem bestimmten mitteilungsbasierten oder anderen Format bestimmte Referenzdaten 22 benötigt.
A. Logische Datendienstarchitektur
4 zeigt ein Beispiel einer logischen Datendienstarchitektur 50 auf hoher Ebene für ein MDM-System 4. In einem Ausführungsbeispiel enthält die Datendienstarchitektur 50 primäre Ebenen: (1) eine „Front-Side" Datendienstebene 52a; (2) eine physische Datenebene 54; und (3) eine „Back-Side" Datendienstebene 52b. Die Front-Side Datendienstebene 52a ist der Front-Side Datenzugriffsebene 42a zugeordnet, die oben unter Bezugnahme auf 3 beschrieben wurde, und stellt einen direkten Datenzugriff auf interne MDM-Dienste 34 zur Verfügung, die direkt auf das MDM-Kernreferenzdatendepot innerhalb der Datenbank 36 zugreifen. So kann die Front-Side Datendienstebene 52az.B. direkten Zugriff auf die Datenbank 36 für interne Analysen oder Benutzeroberflächen-Dienstanfragen zur Verfügung stellen. Die physische Datenebene 54 enthält die Datenbank 36, in der das MDM-Kernreferenzdatenmodell liegt. Die Back-Side Datendienstebene 52b ist der Back-Side Datenzugriffsebene 42b zugeordnet, die oben unter Bezugnahme auf 3 beschrieben wurde, und stellt einen indirekten Datenzugriff auf externe Betriebsdienste 56 zur Verfügung, die externen Betriebssystemen 40 zugeordnet sind, die wiederum indirekten Zugriff auf das MDM- Kernreferenzdatendepot innerhalb der Datenbank 36 haben. So kann die Back-Side Datendienstebene 52b z.B. Betriebsdienste mit indirektem Zugriff auf die Datenbank 36 über Bereitstellungsbereiche der Datenbank 36, Bereitstellungsbereiche, die externen Betriebssystemen 40 zugeordnet sind, und dauerhafte Datenspeicher, die externen Betriebssystemen 40 zugeordnet sind, zur Verfügung stellen. In einer physischen Anordnung kann jede der drei primären Ebenen der Datendienstarchitektur 50 den entsprechenden Technologiekomponenten zugewiesen werden.
Die Front-Side Datendienstebene 52a kann einer entsprechenden objektbasierten Dienstebene zugewiesen werden, wie z.B. der Common Object Request Broker Architecture (CORBA) oder JAVA 2 PLATFORM ENTERPRISE EDITION (J2EE), die sich auf einem entsprechenden Anwendungsserver innerhalb einer Anwendungsdienstebene befindet (unten beschrieben unter Bezugnahme auf 9). In bestimmten Ausführungsbeispielen kann die Front-Side Datendienstebene 52a enger mit der physischen Datenebene 54 verbunden sein, da eine Objekt-Relations-Übergangsebene als Teil der Front-Side Datendienstebene 52a erforderlich ist.
Die Datenbank 36 innerhalb der physischen Datenebene 54 kann als eine relationale Datenbank umgesetzt werden. Die Datenbank 36 kann auf unterschiedliche Art und Weise angelegt und verwaltet werden, wobei eine dieser Arten für eine bestimmte Umsetzung gewählt werden kann. In einem Ausführungsbeispiel kann objektbezogene Datenbankverwaltungstechnologie verwendet werden, obwohl dieser Ansatz gewöhnlich Leistungsrisiken unterliegt. Mit diesem Ansatz kann das MDM-Kernreferenzdatenmodell unter Verwendung einer entsprechenden objektbezogenen Zuweisungsebene existierenden Diensten 34 zugewiesen werden. In einem alternativen Ausführungsbeispiel kann zur Leistungsverbesserung oder aus anderen Gründen eine feststehende datenmodellbezogene Datenbank mit einer leichten Zugriffsebene verwendet werden. Die leichte Zugriffsebene würde beständige Objekte zur Verfügung stellen, die auf das feststehende und optimierte physische Schema der relationalen Datenbank zugeschnitten sind und nicht das physische Schema durch eine objektbezogene Zuweisungsebene steuern. Mit diesem Ansatz können einem vorhandenen MDM-Kernreferenzdatendepot neue Dienste 34 zugewiesen werden.
Obwohl ein einzelnes MDM-Kernreferenzdatendepot innerhalb einer einzelnen Datenbank 36 hier primär aus Gründen der Einfachheit beschrieben wird, ist die vorliegende Erfindung auf jede beliebige Anzahl von MDM-Kernreferenzdatendepots innerhalb jeder Anzahl von Datenbanken 36 entsprechend bestimmter Anforderungen ausgerichtet. Jedoch unterliegen alle MDM-Kernreferenzdatendepots innerhalb aller Datenbanken 36 einer zentralisierten Datenverwaltung, die einem einzelnen MDM-System 4 zugeordnet ist, und erscheinen vorzugsweise sowohl gegenüber den internen MDM-Diensten 34 als auch den externen Betriebsdiensten 56 als ein einzelnes MDM-Kernreferenzdatendepot.
Die Back-Side Datendienstebene 52b ist vorzugsweise für potentiell umfangreiche Datensynchronisierungs- und Nachbildungsvorgänge optimiert, vorzugsweise durch Einbeziehung von Netzwechseltechniken, effizienten Speicherablauftechniken und einer objektbasierten Kontrollebene. Da die Back-Side Datendienstebene 52b darüber hinaus der Planung, Ausführung, Überwachung oder anderen Unternehmenslösungskomponenten 6 zugewiesen wird, für die Datenübertragungen und entsprechende Zuweisungen (d.h. Übertragungen) im Laufe der Zeit angemessen fest bleiben müssen, sollte das MDM-Kernreferenzdatenmodell ebenfalls im Laufe der Zeit angemessen fest bleiben.
B. Logische Datendepotarchitektur
5 zeigt ein Beispiel einer logischen Architektur 70 der Datenbank 36 auf hoher Ebene. In einem Ausführungsbeispiel schließt die Datenbank 36 einen konsistenten, dimensionalen Modellgefüge ein, der auf ein Modell angewendet wird, das einen Beständigkeitsverwaltungsdienst unterstützt, der weiter unten detailliert beschrieben wird. Dies erlaubt es vorzugsweise einem Dienstegefüge 32, Referenzdaten 22 innerhalb der Datenbank 36 in einer Weise zu verwalten, die mit etablierten dimensionalen Ansichten der Referenzdaten 22 konsistent ist. Wenn das MDM-System 4 nicht physisch alle Referenzdaten 22 enthält, erscheinen Referenzdaten 22, die nicht physisch im MDM-System 4 enthalten sind, vorzugsweise so, als ob sie physisch im MDM-System 4 enthalten wären. Die Datenbank 36 enthält einen Bereich für verwaltete Daten 72, der Referenzdaten 22 enthält, von denen zumindest ein Teil fern vom MDM-System 4 verwaltet werden kann. Der Bereich für verwaltete Daten 72 stellt das MDM-Kernreferenzdatendepot für Referenzdaten 22 zur Verfügung. Die Datenbank 36 kann außerdem einen Bereich für zwischengespeicherte Daten 74 enthalten, der zwischengespeicherte Daten 76 enthält, die Referenzdaten 22 repräsentieren, die aus dem Bereich für verwaltete Daten 72 extrahiert wurden, entsprechend den Anforderungen eines oder mehrerer Elemente des MDM-Systems 4 unter Verwendung eines Datenverwaltungsgefüges 78 weiterverarbeitet werden und als Referenzdaten 22 wieder in den Bereich für verwaltete Daten 72 eingeführt werden, sobald die Weiterverarbeitung beendet ist. So kann der Datenverwaltungsgefüge 78 z.B. den Prozess-Controller innerhalb des Geschäftsprozess-Toolkits 34a, der UI-Dienste 34d oder jedes beliebigen anderen geeigneten Elements des MDM-Systems 4 mit Betriebszugriff auf die zwischengespeicherten Daten 76 zur Verfügung stellen.
Referenzdaten 22, die innerhalb des MDM-Systems 4 gespeichert sind, verfügen über einen zugeordneten Status, der mit ihrer Verwendung konsistent ist. In einem Ausführungsbeispiel stellt der Bereich für zwischengespeicherte Daten 74 in Verbindung mit dem Datenverwaltungsgefüge 78 einen Mechanismus zur Verfügung, der eine Kopie von Referenzdaten 22 zur Manipulation zurückhält, während der Status der Referenzdaten 22 im Bereich für verwaltete Daten 72 als gesperrt zum Nur-Lesezugriff aufrecht erhalten wird, bis der Manipulationsvorgang abgeschlossen ist. Sobald eine Kopie der Referenzdaten 22 sich während des Manipulationsvorgangs als zwischengespeicherte Daten 76 im Bereich für zwischengespeicherte Daten 74 befindet, sieht der Manipulationsvorgang nur den Status der zwischengespeicherten Daten 76 im Bereich für zwischengespeicherte Daten 74, während andere Prozesse, Dienste und Systeme, die dem MDM-System 4 zugeordnet sind, den tatsächlichen Status der Referenzdaten 22 im Bereich für verwaltete Daten 72 sehen, und nicht den vorübergehenden Status, der den noch nicht abgeschlossenen Manipulationsvorgang widerspiegelt.
Die Datenbank 36 kann außerdem einen Betriebszugriffsbereich 80 enthalten, der ein oder mehrere externe Betriebssysteme 40 Zugriff auf Referenzdaten 22 innerhalb des Bereichs für verwaltete Daten 72 zur Verfügung stellt. Wenn das MDM-System 4 einem Beispiels-Einzelhandelsunternehmen zugeordnet ist, können externe Betriebssysteme 40 dem Unternehmen zugeordnete externe Unternehmen, wie z.B. Hersteller, Vertriebshändler und Verkäufer von Artikeln, enthalten. Externe Betriebssysteme 40 können auch Planungs-, Ausführungs-, Überwachungs- und andere Unternehmenslösungskomponenten 6 innerhalb des Unternehmens enthalten, die außerhalb des MDM-Systems 4 liegen. Der Betriebszugriffsbereich 80 kann eine Stammdatenkopie 82 eines Lightweight Directory Access Protocol-Depot (LDAP) enthalten, das zur Bereitstellung von Authentifizierungs- und Autorisierungs-Diensten verwendet werden kann, wie weiter unten detailliert beschrieben wird. Der Betriebszugriffsbereich 80 kann außerdem die Bereitstellungsbereiche für ein- und ausgehende Daten 66 bzw. 68 für Daten enthalten, die von externen Betriebssystemen 40 eingehen oder an diese gesendet werden.
C. Informationsverteilungs-Architektur
In einem Ausführungsbeispiel können Daten aus jeder geeigneten Quelle in das MDM-System 4 gelangen und das MDM-System 4 mit jedem geeigneten Ziel verlassen. Wenn keine Referenzdaten 22, die im MDM-Kernreferenzdatendepot gespeichert sind, problemlos für externe Betriebssysteme 40 zur Verfügung gestellt werden können, hat das Speichern von Referenzdaten 22 im MDM-Kernreferenzdatendepot unter Umständen wenig Sinn für das Unternehmen. Umgekehrt können andere Daten in Bereichen des Unternehmens vorhanden sein, die über das MDM-System 4 in andere Bereiche des Unternehmens befördert werden müssen. 6 zeigt ein Beispiel einer Informationsverteilungs-Architektur 90 für das MDM-System 4. In einem Ausführungsbeispiel kann die Datenbank 36 eher für die Verwaltung von Referenzdaten 22 als für schnellen Dateneingang oder -ausgang optimiert werden. Dementsprechend kann eine Bereitstellungsstrategie eingeführt werden, um die Datentransferzeiten zu und von externen Betriebssystemen 40 zu minimieren.
Wie oben beschrieben, können eingehende Daten von einer oder mehreren Datenquellen 92 zum Speichern im MDM-Kernreferenzdatendepot des Bereichs für verwaltete Daten 72 empfangen werden. Datenquellen 92 können beständige Datenspeicher enthalten, die externen Unternehmen 40a, wie z.B. Herstellern, Vertriebshändlern, Verkäufern und Kunden, zugeordnet sind, wenn das MDM-System 4 einem Beispiel-Einzelhandelunternehmen zugeordnet ist. Datenquellen 92 können außerdem betriebliche Bereitstellungsdatenspeicher enthalten, die der Planung, Ausführung, Überwachung oder anderen Unternehmenslösungskomponenten 6 zugeordnet sind. Die eingehenden Daten werden zuerst in Bereitstellungstabellen für eingehende Daten 94 im Bereitstellungsbereich für eingehende Daten 84 und dann als Referenzdaten 22 in MDM-Kerntabellen 96 im MDM-Kernreferenzdatendepot des Bereichs für verwaltete Daten 72 verschoben. Während der Übertragung der Daten vom Bereitstellungsbereich für eingehende Daten 84 in das MDM-Kernreferenzdatendepot des Bereichs für verwaltete Daten 72 können gegebenenfalls Daten gesäubert, geprüft und transformiert sowie andere Prozesse ausgeführt werden. So kann es z.B. sehr wichtig sein, dass Referenzdaten 22, die im MDM-Kernreferenzdatendepot gespeichert und externen Betriebssystemen 40 zugänglich gemacht werden, durch die Datensäuberung beim Laden eingehender Daten als sauber betrachtet werden können.
Wie oben beschrieben, können ausgehende Daten an ein oder mehrere Datenziele 98 übertragen werden, wie z.B. beständige Datenspeicher, die externen Unternehmen 40a zugeordnet sind, oder betriebliche Bereitstellungsdatenspeicher, die der Planung, Ausführung, Überwachung oder anderen externen Unternehmenslösungskomponenten 6 zugeordnet sind. Ausgehende Daten, die unter Verwendung des MDM-Systems 4 verteilt und nicht im MDM-Kernreferenzdatendepot gespeichert werden, können von Bereitstellungstabellen für eingehende Daten 94 des Bereitstellungsbereiches für eingehende Daten 84 an Bereitstellungstabellen für ausgehende Daten 100a des unverbundenen Bereitstellungsbereiches für ausgehende Daten 86a und dann an die Datenziele 98 gesendet werden. Entsprechend können ausgehende Referenzdaten 22 im MDM-Kernreferenzdatendepot des Bereichs für verwaltete Daten 72 aus den MDM-Kerntabellen 96 des Bereichs für verwaltete Daten 72 an Bereitstellungstabellen für ausgehende Daten 100b des verbundenen Bereitstellungsbereichs für ausgehende Daten 86b und dann an die Datenziele 98 übertragen werden. Referenzdaten 22, die innerhalb von MDM-Kerntabellen 96 gespeichert sind, können im Wesentlichen kontinuierlich mit den ausgehenden Daten in Bereitstellungstabellen für ausgehende Daten 100 synchronisiert werden, so dass zu jedem Zeitpunkt eine genaue Momentaufnahme von Referenzdaten 22 innerhalb des Bereitstellungsbereichs für ausgehende Daten 86 verfügbar ist. Die Synchronisierung von Referenzdaten mit Betriebsdaten kann wichtig sein, wenn z.B. sichergestellt werden soll, dass ein Plan, der auf Betriebsdaten basiert, nicht ausgeführt wird für eine Entität, die innerhalb des Unternehmens nicht mehr so vorhanden ist, wie sie in den Referenzdaten 22 dargestellt ist. Datentransformationen oder andere Verarbeitungsformen können gegebenenfalls während der Weiterleitung von Referenzdaten 22 von dem MDM-Kernreferenzdatendepot des Bereichs für verwaltete Daten 72 an den Bereitstellungsbereich für ausgehende Daten 86 auftreten.
D. MDM-Dienstegefüge
Unter erneuter Bezugnahme auf 3 kann der Dienstegefüge 32 in einem Ausführungsbeispiel Dienste 34 zur Verfügung stellen, die ohne Einschränkung in die folgenden Gruppierungen unterteilt werden können: (1) Geschäftsprozess-Toolkit 34a; (2) Sicherheitsdienste 34b, (3) allgemeine Dienste 34c, (4) Benutzeroberflächendienste 34d, (5) Datenzugriffsdienste 34e, und (6) Datenbereitstellungsdienste 34f.

1. Geschäftsprozess-Toolkit Das Geschäftsprozess-Toolkit 34a kann unter Verwendung eines entsprechenden Untersystems innerhalb des Dienstegefiges 32 zur Verfügung gestellt werden, dessen Aufgabe die Verwaltung von MDM-Modellen, Prozessen und zugeordneten Geschäftsregeln ist. Automatisierte Abläufe, die diesem Untersystem zugeordnet sind, können genutzt werden, um Modelländerungen einzuführen, die der physischen Umsetzung des MDM-Systems 4 zugeordnet sind. In einem Ausführungsbeispiel kann das Geschäftsprozess-Toolkit 34a ohne Einschränkung enthalten: (1) ein MDM-Studio, (2) eine MDM-Modellbibliothek, (3) einen Geschäftsregel-Verwaltungsdienst, (4) einen Prozess-Controller, und (5) einen MDM-Strukturaktualisierungsdienst. a. MDM-Studio & MDM-Modellbibliothek 7 zeigt ein Beispiel eines MDM-Studios 110 und einer zugeordneten MDM-Modellbibliothek 112, die ein oder mehrere MDM-Modelle 114 enthält, die für das MDM-System 4 geeignet sind. Das MDM-Studio 110 kann Dienste zur Verfügung stellen, die die Struktur des MDM-Systems 4 und seiner Bestandteile formen, z.B. zum Zweck der Konstruktion des MDM-Systems 4 oder zum Zweck der Ausweitung oder anderweitigen Aktualisierung des MDM-Systems 4. Das MDM-Studio 110 kann Unterstützung für eine oder mehrere graphische Modell-Benutzeroberflächen zur Verfügung stellen. Das Modellieren des MDM-Systems 4 kann z.B. das Modellieren von strukturellen Aspekten des MDM-Kernreferenzdatendepots im Bereich für verwaltete Daten 72 der Datenbank 36 enthalten, das Modellieren der Struktur der Bereitstellungsbereiche 66 bzw. 68 der Datenbank 36 und das Modellieren von entsprechenden Prozessabläufen. Das MDM-Studio 110 kann Unterstützung für eine erste Konstruktion von MDM-Modellen 114 sowie für die spätere Erweiterung oder andere Aktualisierungen von MDM-Modellen 114 zur Verfügung stellen. In einem Ausführungsbeispiel enthalten MDM-Modelle 114 ohne Einschränkung: (1) MDM-Prozessmodell 114a, (2) MDM-Dokumentenmodell 114b, (3) MDM-Formenmodell 114c, (4) MDM-Referenzdatenmodell 114d, und (5) MDM-Bereitstellungsdatenmodell 114e. (1) MDM-Prozessmodell Prozessmodelle 114a beschreiben die Prozesse 14, die für die Verwaltung von Referenzdaten 22 verwendet werden, die im MDM-Kernreferenzdatendepot in der Datenbank 36 gespeichert sind. In einem Ausführungsbeispiel beschreibt das entsprechende Prozessmodell 114a für einen bestimmten Prozess 14 die Aufgaben, die in Verbindung mit dem Prozess 14, bestimmten mit diesen Aufgaben verbundenen Diensten 18 und einer oder mehreren bestimmten Prozess-Engines, die für die Ausführung von Prozess 14 verantwortlich sind, auf Referenzdaten 22 ausgeführt werden müssen. Für dienstorientierte Aufgaben können als Beschreibung Web Services Description Language-Protokolle (WSDL) verwendet werden. Jeder Prozess 14 kann einen oder mehrere Aufgabenabläufe in der Benutzeroberfläche, Aufgabenabläufe für Unternehmenslösungskomponenten, zwischenbetriebliche Prozessabläufe oder andere entsprechende Prozesse oder Aufgabenabläufe repräsentieren. Das Prozessmodell 114a kann die Zuordnung jedes Prozesses 14 zu einem Prozess-Controller, Benutzeroberflächen-Controller oder Arbeitsablauf-Controller auf Unternehmensebene spezifizieren. Das Prozessmodell 114a kann auch grafische oder andere Simulationen von Prozessen 14 zur Verfügung stellen. (2) MDM-Dokumentenmodell Das Dokumentenmodell 114b stellt die Metadaten für MDM-Dokumente zur Verfügung, die im Zusammenhang mit Prozessen 14 genutzt werden. In einem Ausführungsbeispiel repräsentieren MDM-Dokumente extern zwischengespeicherte Repräsentationen von spezifischen Metadatenelementen im zugrunde liegenden Referenzdatenmodell 114d. (3) MDM-Formenmodell Das Formenmodell 114c stellt Metadaten zur Verfügung, die Formen beschreiben, die mit Objekten im MDM-Referenzdatenmodell 114d in Zusammenhang stehen. Formen können für die effiziente Extraktion von Metadatenelementen aus dem Referenzdatenmodell 114d wichtig und zu Datenbankansichten analog sein. (4) MDM-Referenzdatenmodell Das Referenzdatenmodell 114d repräsentiert die Metadaten, die die Referenzdaten 22 beschreiben, die im MDM-Kernreferenzdatendepot gespeichert sind. Dies ist die unterste Ebene der Metadaten-Repräsentation, die in der Modellbibliothek 112 enthalten ist. In einem Ausführungsbeispiel kann das MDM-Referenzdatenmodell 114d ein Unternehmensmetamodell im Format Extensible Markup Language (XML) Software Description (XSD) sein, das Instanzdaten in einer Weise von Metadaten trennen kann, die für die Verwaltung wünschenswert ist, und das die Back-Side Datenzugriffsebene 42b direkt aus der MDM-Modellbibliothek 112 lesen kann. Es kann wichtig sein, Änderungen am MDM-Referenzdatenmodell 114d mit Konstrukten aller höheren Ebenen, wie z.B. dem Formenmodell 114c oder dem Dokumentenmodell 114b, zu synchronisieren. Die Synchronisierung der Modelle 114 kann automatisch durchgeführt werden, oder das Studio 110 kann gegebenenfalls erforderliche Änderungen kennzeichnen und einen verwaltenden Benutzer durch die Synchronisierung der Modelle 114 führen.
Ein generisches Datenmodell für Referenzdaten 22, die im MDM-Kernreferenzdatendepot gespeichert werden sollen, kann so konstruiert sein, dass es eine Synthese aller anwendbaren Datenelemente darstellt, also z.B. aller Datenelemente, die Unternehmen in der Einzelhandelsbranche zugeordnet sind, und als Obermenge von Referenzdatenmodellen 114d gesehen werden kann, die in tatsächlichen Umsetzungen des MDM-Systems 4 verwendet werden können. Das generische Referenzdatenmodell und alle vom generischen Referenzdatenmodell abstammenden Referenzdatenmodelle 114d sollten aus Gründen der Konsistenz und der effizienten Verwaltung aus Referenzdaten 22 konstruiert werden. In einem Ausführungsbeispiel kann das generische Referenzdatenmodell als ein Dokument in einem RATIONAL ROSE-Objektmodell dargestellt werden. (5) MDM-Bereitstellungsdatenmodell sDas Bereitstellungsdatenmodell 114e repräsentiert Metadaten, die jeweils die Struktur der Bereitstellungstabellen für eingehende und ausgehende Daten 94 bzw. 78 sowie die Zuweisung zwischen dem Referenzdatenmodell 114d und den Bereitstellungstabellen für eingehende und ausgehende Daten 94 bzw. 78 beschreiben. Das Referenzdatenmodell 114d kann ein normiertes Datenmodell sein, das von einem generischen Referenzdatenmodell wie oben beschrieben abstammt. Eingehende Daten können jedoch beliebige Schemata widerspiegeln, die mit dem Referenzdatenmodell 114d inkonsistent sind. Für eingehende Daten können entsprechende Zuweisungen (d.h. Transformationen) des Referenzdatenmodells 114d zu Quelldatenmodellen, wie z.B. einem Bereitstellungsdatenmodell für eingehende Daten 114e, die ein beliebiges Eingangsdatenformat für ein externes Betriebssystem 40 repräsentieren, ausgeführt werden, wenn eingehende Daten im MDM-Kernreferenzdatendepot gespeichert werden. Entsprechend müssen ausgehende Daten möglicherweise für die Nutzung als Betriebsdaten entnormiert werden. Für ausgehende Daten können entsprechende Zuweisungen (d.h. Transformationen) des Referenzdatenmodells 114d zu Zieldatenmodellen, wie z.B. einem Bereitstellungsdatenmodell für ausgehende Daten 114e, die ein flaches Ausgabedatenformat für ein externes Betriebssystem 40 repräsentieren, ausgeführt werden, wenn Referenzdaten aus dem MDM-Kernreferenzdatendepot verschoben werden. b. Geschäftsregel-Verwaltungsdienst Unter wiederholter Bezugnahme auf 3 kann der Geschäftsregel-Verwaltungsdienst die Erstellung und Wartung von mit Diensten 18 verbundenen Geschäftsregelelementen, wie z.B. dem Import von Prüfungsregeln, der Bereitstellung von Transformationsregeln und allgemeiner mit dem MDM-System 4 verbundener Konsistenzregeln, ermöglichen. Der Geschäftsregel-Verwaltungsdienst kann skriptbasierte Regeln zur Laufzeit oder die Zuordnung von Regelobjekten aus der Entwurfszeit zu MDM-Prozessabläufen zur Verfügung stellen. c. Prozess-Controller Der Prozess-Controller kann einen Prozessablauf-Controller zur Laufzeit für das MDM-System 4 darstellen. Wie oben beschrieben, kann das Prozessmodell 114a die Zuweisung eines oder mehrerer Prozesse 14 an den Prozess-Controller, einen Benutzeroberflächen-Controller oder einen Arbeitsablauf-Controller auf Unternehmensebene spezifizieren. In einem Ausführungsbeispiel wird der Prozess-Controller zusammen mit jedem beliebigen solcher Benutzeroberflächen-Controller und jedem beliebigen solcher Arbeitsablauf-Controller auf Unternehmensebene betrieben. d. MDM-Strukturaktualisierungsdienst In einem Ausführungsbeispiel stellt das MDM-System 4 einen Mechanismus zur Modellierung seiner Struktur und einen Mechanismus zur Automatisierung eines Prozesses zur Verfügung, um eine Erweiterung des Modells in einer physischen Umsetzung zu realisieren. Der Strukturaktualisierungsdienst kann für die automatisierte Einführung eines Modells 114 sorgen, das während des Modellierprozesses erzeugt oder geändert wird. Der Strukturaktualisierungsdienst kann besonders hinsichtlich der Struktur der Bereitstellungsbereiche für ein- und ausgehende Daten 66 bzw. 68 wichtig sein. Es ist möglicherweise erforderlich, zuerst ein Bereitstellungsdatenmodell 114e zu spezifizieren, das als Referenzmodell für die Struktur des Bereitstellungsbereichs dient. Zusätzlich kann es notwendig sein, eine geeignete Structured Query Language (SQL) oder Änderungen an der SQL zu generieren, damit der Status der Bereitstellungsbereiche 66 bzw. 68 im Verhältnis zum Bereitstellungsdatenmodell 114e erhalten werden kann. Ohne die Automatisierung dieser Aufgaben unter Verwendung des Strukturaktualisierungsdiensts wäre das Aufrechterhalten der Koordination von verschiedenen Elementen des MDM-Systems 4 eine äußerst aufwändige manuelle Aufgabe. Der Strukturaktualisierungsdienst kann außerdem auf mit den Unternehmenslösungskomponenten 6 zur Verfügung gestellte Aktualisierungen reagieren und die Aktualisierung des Bereitstellungsdatenmodells 114e und anderer Modelle 114 sowie der zugewiesenen SQL ermöglichen. Solche Strukturaktualisierungen können mithilfe von Skriptdokumenten mit Aktualisierungsbeschreibungen gesteuert werden, die Informationen zur Verfügung stellen, die für die automatische Ausführung der Strukturaktualisierung erforderlich sind.
2. Sicherheitsdienste Natürlich sollte es nur Nutzern mit entsprechenden Zugriffsrechten erlaubt sein, Referenzdaten 22 innerhalb des MDM-Systems 4 zu sichten und zu manipulieren. Sicherheitsdienste 34b können unter Verwendung eines entsprechenden Untersystems innerhalb des Dienstegefiges 32 zur Verfügung gestellt werden und darauf ausgerichtet sein, zwei Hauptaufgaben zu erfüllen. Die erste Aufgabe ist die Kontrolle des Zugriffs auf das MDM-System 4 selbst. Die zweite Aufgabe ist die Verwaltung der Struktur des Sicherheitsmodells, wie es in den Unternehmenslösungskomponenten 6 angewendet wird. Für diese Aufgabe werden Dienste zur Verwaltung des Sicherheitskontexts zur Verfügung gestellt, den alle Unternehmenslösungskomponenten 6 nutzen, z.B. durch ein LDAP-Depot, dessen Stammdatenkopie 82 sich im Betriebszugriffsbereich 80 der Datenbank 36 befindet. Die Sicherheitsdienste 34b können ohne Einschränkung Folgendes enthalten: (1) Authentifizierungsdienste und (2) Autorisierungsdienste. a. Authentifizierung Authentifizierungsdienste stellen eine erste Anmeldungssicherheit hinsichtlich der Unternehmenslösungskomponenten 6 zur Verfügung. Die Authentifizierung basiert vorzugsweise auf einem organisatorischen Modell für das Unternehmen, das einen Sicherheitskontext für alle Unternehmenslösungskomponenten 6 zur Verfügung stellt, welcher jeweils nur eine Anmeldung pro Benutzer zulässt. b. Autorisierung Autorisierungsdienste stellen einen in grobe Ebenen aufgeteilten Zugriff auf spezifische Dienste 18 oder Referenzdaten 22 für authentifizierte Benutzer zur Verfügung. Autorisierung kann auf zwei Ebenen zur Verfügung gestellt werden. Die erste Ebene (Ebene 1) beschäftigt sich mit dem Zugriff auf Unternehmenslösungskomponenten 6 von bestimmten Anwendungen oder Dienstgruppen 18 auf hoher Ebene. Die zweite Ebene (Ebene 2) beschäftigt sich mit dem Zugriff auf spezifische Funktionen innerhalb einer Unternehmenslösungskomponente 6. Die Autorisierung auf Feldebene kann gegebenenfalls von bestimmten Unternehmenslösungskomponenten 6 selbst durchgeführt werden. Im Fall des MDM-Systems 4 muss jede erforderliche Autorisierung höher als Ebene 2 (d.h. Ebene 3 oder höher) möglicherweise innerhalb des MDM-Systems 4 zur Verfügung gestellt werden.
3. Allgemeine Dienste
Allgemeine Dienste 34c können unter Verwendung eines entsprechenden Untersystems innerhalb des Dienstegefüges 32 zur Verfügung gestellt werden und ohne Einschränkung enthalten: (1) einen Änderungsverwaltungsdienst; (2) einen Lebenszyklus- Verwaltungsdienst; (3) einen Gruppenverwaltungsdienst; und (4) einen Analyse- und Berichtdienst. a. Änderungsverwaltung Die Änderungsverwaltungsdienste stellen einen Prüfpfad für Änderungen zur Verfügung, die am MDM-System 4 vorgenommen wurden. So können z.B. Informationen darüber gespeichert werden, wer eine Änderung durchgeführt hat, wann die Änderung durchgeführt wurde und eventuell welcher Wert geändert wurde. Der Prüfpfad für Änderungen sollte vorzugsweise so umgesetzt werden, dass der Mechanismus für Informationen, die keine Änderungsverwaltung benötigen, oder für Änderungen, die vor der Konfigurationskontrolle liegen, wie z.B. Änderungen beim ersten Einrichten von Datenelementen, abgeschaltet werden kann. Die logische Gruppierung von Referenzdaten 22 kann für viele Aspekte der Datenverwaltung wichtig sein, wie z.B. für die Gewinnung von Referenzdaten 22 und das Durchführen von Änderungen an Referenzdaten 22. Aus diesem Grund ist die Einteilung der Änderungsverwaltung in einem Ausführungsbeispiel gruppenbasiert und Änderungen werden auf der Gruppenmitgliedsebene ausgeführt. b. Lebenszyklus-Verwaltung Wie oben beschrieben, ist den Referenzdaten 22, die in einem MDM-System 4 gespeichert sind, ein Status zugeordnet, der mit ihrer Verwendung konsistent ist. Der Lebenszyklus-Verwaltungsdienst erlaubt eine Definition eines Lebenszyklus, der die möglichen Statuseigenschaften von Datenelementen und den Mechanismus beschreibt, der für die Verwaltung der Datenübertragung von einem Lebenszyklus in einen anderen verwendet wird. c. Gruppenverwaltung Angesichts des großen Umfangs und der Reichweite von Daten, die in einem MDM-System 4 vorhanden sein können, ist eine Gesamtstrategie für die Datenverwaltung vorzuziehen, die auf logischen Gruppen von Daten und nicht auf individuellen Datenelementen basiert. Die logische Gruppierung von Referenzdaten 22 kann für viele Aspekte der Datenverwaltung wichtig sein, wie z.B. für die Gewinnung von Referenzdaten 22 und das Durchführen von Änderungen an Referenzdaten 22. Obwohl auch einzelne Entitäten manipuliert werden können, werden viele Aktualisierungen gewöhnlich auf Entitätengruppen angewendet. In einem Ausführungsbeispiel wird der Gruppenaspekt der Datenmanipulation von Grund auf in das MDM-System 4 eingebaut. d. Analysen und Berichte Der Zustand und Status eines großen Datendepots wie dem MDM-Kernreferenzdatendepot in der Datenbank 36 sind äußerst wichtig. Der Analyse- und Berichtdienst stellt Informationen über die Referenzdaten 22, welche im MDM-Kernreferenzdatendepot gespeichert werden, und über den Status der unterschiedlichen Systemelemente des MDM-Systems 4 zur Verfügung. Obwohl die Analysetypen und die entsprechenden Berichte für das MDM-System 4 spezifisch sind, können, sofern geeignet, allgemeine Analyse- und Berichts-Tools verwendet werden. Die Analyse kann auf eine Vielzahl von Aktivitäten ausgedehnt werden, die direkt von diesem Dienst oder indirekt durch die Verwaltung von diesem Dienst unterstützt werden. Die Analyse kann Gruppierungsdienste für Attribute/Eigenschaften, Aktivitäten zur Entscheidungsunterstützung bei im MDM-Kernreferenzdatendepot gespeicherten Entitätendaten, die Verwaltung von Parameterberechnung wie z.B. die Koordinierung von Parameterberechnung unter Verwendung einer externen Engine, die Aktualisierung von Parametern wie z.B. der Durchlaufzeit von Artikeln an bestimmten Orten sowie alle anderen entsprechenden Analysen enthalten. Berichte können Änderungsprotokollaktivitäten, Ablaufverfolgung für bestimmte Entitäten oder Entitätengruppen, Berichte über Produktionsparameterreihen inklusive terminierter Reihen, Kalenderüberprüfung und -abgleich, Berichte über neu in das MDM-Kernreferenzdatendepot aufgenommene Entitäten (wie z.B. neue Artikel) und Berichte über alte, aus dem MDM-Kernreferenzdatendepot entfernte Entitäten (wie z.B. Artikel) sowie alle anderen entsprechenden Berichte enthalten.
4. Benutzeroberflächendienste
5. Datenzugriffsdienste Datenzugriffsdienste 34e können durch die Verwendung eines entsprechenden Untersystems im Dienstegefüge 32 zur Verfügung gestellt werden, durch das eine entscheidende Schnittstelle zwischen den Ebenen der Benutzeroberfläche, den Geschäftsregeln zur Datenverwaltung und dem zugrunde liegenden MDM-Kernreferenzdatendepot in der Datenbank 36 zur Verfügung gestellt wird. Datenzugriffsdienste 34e können in dem Datenverwaltungsgefüge 78 enthalten sein, der oben unter Bezugnahme auf 5 beschrieben wurde. Da in einem Ausführungsbeispiel die überwiegende Ansicht von Referenzdaten 22 objektbasiert ist, können Datenzugriffsdienste 34e eine beständige Zuweisung zu zugrunde liegenden Datenstrukturen in der Datenbank 36 unterstützen. Entsprechend können die Datenzugriffsdienste 34e in einem Ausführungsbeispiel das Konzept eines Datenzwischenspeichers beinhalten, wie z.B. den oben beschriebenen Bereich für zwischengespeicherte Daten 74 in der Datenbank 36, der einen Mechanismus zur Verfügung stellt, der eine Kopie von Referenzdaten 22 im Bereich für zwischengespeicherte Daten 74 zur Manipulation zurückhält, während der Status der Referenzdaten im MDM-Kernreferenzdatendepot des Bereichs für verwaltete Daten 72 als gesperrt zum Nur-Lesezugriff aufrecht erhalten wird, bis der Manipulationsvorgang abgeschlossen ist. Sobald eine Kopie der Referenzdaten 22 sich während des Manipulationsvorgangs als zwischengespeicherte Daten 76 im Bereich für zwischengespeicherte Daten 74 befindet, sieht der Manipulationsvorgang nur den Status der zwischengespeicherten Daten 76 im Bereich für zwischengespeicherte Daten 74, während andere Prozesse, Dienste und Systeme, die dem MDM-System 4 zugeordnet sind, den tatsächlichen Status der Referenzdaten 22 im Bereich für verwaltete Daten 72 sehen und nicht den vorübergehenden Status, der den noch nicht abgeschlossenen Manipulationsvorgang widerspiegelt. Datenzugriffsdienste 34e können ohne Einschränkung Folgendes enthalten: (1) einen Beständigkeitsverwaltungsdienst, und (2) einen Datenzugriffsebenendienst. a. Beständigkeitsverwaltung Der Beständigkeitsverwaltungsdienst stellt die logische Zuweisung zwischen der Benutzeransicht der Referenzdaten 22 und dem zugrunde liegenden beständigen Objektmodell zur Verfügung, das den Referenzdaten 22 zugeordnet ist. Der Dienst sorgt für die Verwaltung der Erstellung, Aktualisierung und Löschung von Modellinstanzen, einschließlich entsprechender Zwischenspeichern von beständigen Objekte auf Speicherebene. b. Datenzugriffsebene Der Datenzugriffsebenendienst stellt die Verbindung zwischen dem logischen Objektmodell, das den Referenzdaten 22 zugeordnet ist, und den physischen Instanzen von relationalen MDM-Kerntabellen 96, in denen die beständigen Objekte als Referenzdaten 22 gehalten werden, zur Verfügung. Die Trennung der Beständigkeitsebene von einer bestimmten physischen Zuweisungsebene erlaubt eine Vielzahl physischer Ziele, was besonders nützlich ist, wenn ein verteiltes, physisches Datenmodell erforderlich ist (z.B. in bestimmten Fällen der Parameterwartung).
6. Datenbereitstellungsdienste Datenbereitstellungsdienste 34e können unter Verwendung eines entsprechenden Untersystems innerhalb des Dienstegefiges 32 zur Verfügung gestellt werden und dienen hauptsächlich der Synchronisierung der Bereitstellungsbereiche für eingehende und ausgehende Daten 66 bzw. 68 mit dem Bereich für verwaltete Daten 72 der Datenbank 36. Datenbereitstellungsdienste 34e können ohne Einschränkung enthalten: (1) einen Datenimportdienst; (2) einen Überprüfungsdienst; und (3) einen Syndizierungsdienst. a. Datenimport Der Datenimportdienst stellt Funktionen für die Übertragung von Daten aus externen Quellen in die Datenbank 36 zur Verfügung. Der Datenimportdienst kann z.B. dazu verwendet werden, vorhandene Stammdaten zur Speicherung und späteren Weiterleitung an eine oder mehrere Planungs-, Ausführungs-, Überwachungs-, oder andere Unternehmenslösungskomponenten 6 in die Datenbank 36 zu übertragen. Das Importieren von Daten enthält das Übertragen von eingehenden Daten in den Bereitstellungsbereich für eingehende Daten 84, gegebenenfalls das Überprüfen und Transformieren der eingehenden Daten und das Übertragen der eingehenden Daten aus dem Bereitstellungsbereich für eingehende Daten 84 in das MDM-Kernreferenzdatendepot des Bereichs für verwaltete Daten 72 als Referenzdaten 22. b. Überprüfung Der Überprüfungsdienst erlaubt die Anwendung vordefinierter sowie benutzerdefinierter Überprüfungsregeln auf eingehende Daten, bevor diese in die Datenbank 36 eingefügt werden. Überprüfungsregeln können grundlegende Werttypregeln, verweisende Integritätsregeln, unternehmensspezifische Geschäftsregeln oder alle anderen entsprechenden Regeln enthalten. In einem Ausführungsbeispiel kann die Überprüfung so ausgewählt werden, dass höhere Überprüfungsebenen angewendet werden können, wenn ein eingehender Datensatz „verschmutzt" ist und eine strengere Überprüfung erfordert. Dagegen können niedrigere Überprüfungsebenen angewendet werden, wenn eingehende Datensätze als „sauber" gewertet werden und eine weniger strenge Überprüfung erforderlich ist. c. Syndizierung Der Syndizierungsdienst, der hauptsächlich Daten aus der Datenbank 36 für die Planung, Ausführung, Überwachung oder andere Unternehmenslösungskomponenten 6 exportiert, kann zwei primäre Elemente enthalten. Das erste Element stellt Funktionen zur Synchronisierung von MDM-Kerntabellen 96 im Bereich für verwaltete Daten 72 mit Bereitstellungstabellen für ausgehende Daten 100 im Bereitstellungsbereich für ausgehende Daten 86 zur Verfügung, so dass innerhalb der Bereitstellungstabellen für ausgehende Daten 100 zu jedem Zeitpunkt eine gültige Momentaufnahme der Referenzdaten 22 vorhanden ist, die mit den Beschränkungen der Aktualisierungstransaktionen konsistent ist. Das zweite Element stellt Funktionen für termin- oder nachfragebasierte Datenübertragungen aus den Bereitstellungstabellen für ausgehende Daten 100 in eine Ziel-Unternehmenslösungskomponente 6 zur Verfügung.

IV. MDM-Verwendungsmodell
8 zeigt ein Beispiel eines MDM-Verwendungsmodells 130 für das MDM-System 4. Im Allgemeinen beschreibt das Verwendungsmodell 130, wie das MDM-System 4 verwendet wird, d.h. wo Daten gespeichert werden und wie auf die Daten zugegriffen wird. In einem Ausführungsbeispiel sehen die externen Betriebssysteme 40, die mit dem MDM-System 4 interagieren, das MDM-System 4 als Referenzdatendepot, nicht als Betriebsdatenquelle. Entsprechend können Referenzdaten 22 im MDM-Kernreferenzdatendepot 132 synchronisiert werden und durch entsprechende externe Zugriffsdienste 136, die mit einer oder beiden Datenzugriffsebenen 42 zusammenarbeiten, an lokale beständige Speicher 134 externer Betriebssysteme 40 repliziert werden. Interne Zugriffsdienste 138, die der Verwaltung von Referenzdaten 22 im MDM-System 4 zugeordnet sind, haben möglicherweise direkten Zugriff auf Referenzdaten 22 im MDM-Kernreferenzdatendepot 132. Im Gegensatz hierzu können Betriebsdienste 140 von externen Betriebssystemen 40, die nicht der Verwaltung von Referenzdaten 22 im MDM-System 4 zugeordnet sind, nur auf Daten in den zugeordneten beständigen Speichern 134 und niemals direkt auf Referenzdaten 22 im MDM-Kernreferenzdatendepot 132 zugreifen. Somit kann das MDM-System 4 im Wesentlichen als ein sicheres Aufzeichnungssystem auftreten, dessen Architektur und Design für die Verwaltung von Referenzdaten 22 und nicht für die betriebliche Verwendung von Referenzdaten 22 optimiert ist. Verbrauchsdienste ohne Bezug zur Verwaltung von Referenzdaten 22 dürfen nicht direkt auf Referenzdaten 22 zugreifen.
In einem Ausführungsbeispiel enthalten die entscheidenden Maße, die beim Entwerfen einer physischen Architektur im Einklang mit dem Verwendungsmodell 130 berücksichtigt werden müssen, ohne Einschränkung: (1) Durchsatzleistung; (2) Abfrageleistung; (3) Flexibilität der Konfiguration; und (4) Skalierbarkeit. Jedes dieser Maße wird unten hinsichtlich der entsprechenden physischen Eigenschaften bei der Einführung des MDM-Systems 4 beschrieben.
A. Durchsatzleistung
Das primäre Verwendungsmodell für das MDM-System 4 verfügt über ein zentralisiertes Stammdepot, ein MDM-Kernreferenzdatendepot 132 des Bereichs fiür verwaltete Daten 72 der Datenbank 36 für die Kernunternehmensdaten, die Referenzdaten 22. In einem Ausführungsbeispiel ist es ein Ziel, das MDM-Kernreferenzdatendepot 132 vor dem betrieblichem Ladevorgang zu schützen, während optimales Design für externe Betriebssysteme 40 erlaubt wird, die Referenzdaten 22 in einem Betriebsmodus verwenden. Entsprechend erfordert das Verwendungsmodell 130, wie oben detaillierter beschrieben, die Synchronisierung und Nachbildung von Referenzdaten 22 in lokalen beständigen Speichern 134 externer Betriebssysteme 40, die Referenzdaten 22 verwenden. Dies impliziert eine physische Architektur und ein physisches Design, die die Durchsatzleistung ausgehender Daten für die Übertragung von Referenzdaten 22 aus dem MDM-Kernreferenzdatendepot 132 in beständige Zielspeicher 134 ermöglichen. Wenn Referenzdaten 22 in großen Mengen von externen Betriebssystemen 40 in das MDM-System 4 übertragen werden, sollten die physische Architektur und das physische Design vorzugsweise auch die Durchsatzleistung für eingehende Daten unterstützen. Ein daraus folgendes primäres Design-Kriterium ist, dass die physische Datenebene 54 einen möglichst effizienten Zugriff auf die Referenzdaten 22 ermöglichen sollte. Es kann wünschenswert sein, Umwegebenen zu berücksichtigen, die zwischen den Referenzdaten 22 enthaltenden MDM-Kerntabellen 96, die eine relationale Tabellenstruktur aufweisen können, und der externen Repräsentation von Referenzdaten 22, die eine Objektrepräsentation darstellen können, liegen.
B. Abfrageleistung
Der Kontext für die Abfrageleistung ist das Erstellen von Ansichten von Referenzdaten 22 für die MDM-Benutzeroberfläche oder einen Analysedienst im MDM-System 4, wie z.B. der oben unter Bezugnahme auf 3 beschriebene Analyse- und Berichtdienst. Solche Benutzeroberflächen- und Analysedienst-Abfragen sind wahrscheinlich eher filtergesteuert und suchen nach bestimmten Teilmengen von Referenzdaten 22 innerhalb eines wesentlich größeren Zeilenkontextes als jede SQL-Abfrage oder andere Abfragen, die mit dem Massen-Export von Referenzdaten 22 in Zusammenhang stehen, der oben in Verbindung mit dem Durchsatz beschrieben wurde. Die Struktur der physischen Datenebene 54 und des entsprechenden Datenzugriffsebenendiensts sollte so ausgerichtet sein, dass gegebenenfalls eine Vielzahl komplexer Anfragen in angemessener Zeit bearbeitet werden kann. Die Rückgabe großer und kleiner Zeilensätze mit komplexen Abfragen sollte möglichst unabhängig vom Zieldienst (z.B. der Benutzeroberfläche) sein. Designkriterien für die Abfrageleistung können Abfragen mit niedriger durchschnittlicher Beantwortungszeit auf Datenbankebene, ausreichende Leistung bei starker Eingangsbelastung durch eine Vielzahl eingehender Abfragen und minimale Wartezeit im zugeordneten Datenzugriffsebenendienst sein.
C. Flexibilität der Konfiguration
Die Flexibilität der Konfiguration kann sowohl aus der Sicht des Benutzers als auch aus der Sicht der Lösung betrachtet werden. Aus der Sicht des Benutzers müssen die Referenzdaten 22, die im MDM-Kernreferenzdatendepot 132 enthalten sind, einer bestimmten Datenansicht zugewiesen werden, die das Unternehmen benötigt. Aus der Sicht der Lösung, bei der die entscheidenden Maßeinheiten gewöhnlich die Leistung bei der Nachbildung und die Abfrageleistung sind, ist die Flexibilität der Konfiguration möglicherweise von geringerer Bedeutung oder sogar diesen Erfordernissen abträglich. Im Allgemeinen wäre es nicht ratsam, das Referenzdatenmodell 94d für jede Umsetzung im Unternehmen zu ändern, da dies die Neukonfiguration aller Schnittstellen vom MDM-Kernreferenzdatendepot 132 bis hin zu den lokalen beständigen Speichern 134 der externen Betriebssysteme 40 bedeuten würde. Ein Designkriterium für die Flexibilität der Konfiguration ist die Tatsache, dass das Referenzdatenmodell 94d von Umsetzung zu Umsetzung stabil sein sollte und eine Obermenge von erwarteten Referenzdaten 22 für jedes Unternehmen darstellen sollte. Das Erreichen dieses Status kann sich über mehrere Umsetzungen hinziehen, sollte jedoch problemlos innerhalb relativ kurzer Zeit möglich sein, ohne dass dafür das Design des Modells grundlegend geändert werden muss. Wenn eine Zuweisungskonfiguration der Benutzersicht erforderlich ist, sollte diese vorzugsweise in den äußersten Ebenen des Designs stattfinden (d.h. nahe der Benutzeroberfläche und nicht innerhalb der Datenstrukturen des MDM-Kernreferenzdatendepots 132).
D. Skalierbarkeit
Das MDM-Kerneferenzdatendepot 132 kann große Mengen von Referenzdaten 22 enthalten, besonders, wenn das MDM-System 4 einem Beispielhaftes Einzelhandelsunternehmens zugeordnet ist, das über eine große Anzahl von Artikeln, Orten oder anderen Entitäten verfügt. Wenn Attribut-/Eigenschaftsdaten 22e verwendet werden, wobei mehrere hundert Eigenschaftsattribute pro Entität üblich sein können, vermnögen die Referenzdaten 22 sogar über eine noch größere Menge zu verfügen. Diese Eigenschaften können dann zu großen Tabellenzeilenwerten, komplexen relationalen Verbindungen und der Forderung nach einem Dimensionsgefüge für die Referenzdaten 22 führen. Ein Design-Kriterium für die Skalierbarkeit, das sich auch auf Durchsatz und Abfrageleistung bezieht, ist die Fähigkeit, große Zeilensätze effizient zu verarbeiten, wenn die Sätze abgefragt oder übertragen werden. Diese Effizienzarten weisen im Allgemeinen gut entwickelte und gut abgestimmte relationale Tabellen auf, die speziell unter Leistungsgesichtspunkten entworfen wurden. Eine Folge ist, dass das Design vorzugsweise dazu in der Lage sein sollte, parallele Datenbanktechnologien zu nutzen, wenn diese möglicherweise in der Unternehmensumgebung ausreichend skaliert werden können sollten. Wenn das Design keine parallele Datenbanktechnologie nutzen kann, geht diese Möglichkeit verloren, wenn versucht wird, die Leistung durch die Umsetzungskonfiguration zu fördern.
V. Benutzeroberflächen-Architektur
Es gibt verschiedene Triebkräfte für die Architektur und das Design einer Benutzeroberfläche für das MDM-System 4. Eine erste Triebkraft sind die beiden unterschiedlichen Benutzertypen des MDM-Systems 4, einerseits der verwaltende Benutzer und andererseits der am Prozess teilnehmende Benutzer. Die erste Klassifizierung der Benutzerrolle beschäftigt sich primär mit der Verwaltung der Unternehmenskonfigurationsinformationen, die im MDM-System 4 sowie in den zugeordneten MDM-Modellen 114 enthalten sind, die physisch in der Datenbank 36 realisiert werden. Die zweite Klassifizierung der Benutzerrolle beschäftigt sich mehr mit dem Sichten und Eingeben von mit Prozessen 14 verbundenen Informationen, wie z.B. der Einführung eines neuen Artikels. Eine Benutzeroberfläche für ein Modellierungsstudio kann für den verwaltenden Benutzer wichtiger sein, während gut entworfene Bildschirmsequenzen für Ansicht und Eingabe für den am Prozess teilnehmenden Benutzer wichtiger sein können. Die Anforderungen an die Architektur und das Design der Benutzeroberfläche können anhand dieser oder anderer entsprechender Richtlinien aufgeschlüsselt werden. Eine zweite Triebkraft ist die Flexibilität, die Teil der MDM-Architektur ist. In einem Ausführungsbeispiel kann sowohl das MDM-Referenzdatenmodell 114d als auch das Bereitstellungsdatenmodell 114e zum Zeitpunkt der Umsetzung geändert werden. Dies bietet die nötige Flexibilität, um das MDM-System 4 an die Eigenarten des Unternehmens anzupassen. Entsprechend passt die Benutzeroberflächen-Architektur vorzugsweise diese flexiblen Modelle an. Wenn z.B. im Referenzdatenmodell 114d oder im Bereitstellungsdatenmodell 114e ein Feld hinzugefügt oder gelöscht wird, kann ein entsprechender Eingabe-Bildschirm dynamisch an die Modelländerung angepasst werden, ohne dass eine Umprogrammierung erforderlich ist.
VI. Physische MDM-Architektur
9 zeigt ein Beispiel einer physischen Architektur 150 auf hoher Ebene für das MDM-System 4, das frei der oben unter Bezugnahme auf 2 beschriebenen logischen Geschäftsarchitektur 10 und der oben unter Bezugnahme auf 3 beschriebenen logischen technischen Architektur 30 zugewiesen werden kann.
In einem Ausführungsbeispiel enthält das MDM-System 4 einen Webserver 152, eine MDM-Anwendungsserverebene 154, eine Anwendungsserverebene für Infrastrukturdienste 156 und eine MDM-Datenbankebene 158. Unter Verwendung eines Webbrowsers oder auf andere Weise kann ein dem MDM-System 4 zugeordneter Benutzer ein Hypertext Transport Protocol (HTTP) oder eine andere Anfrage an den Webserver 152 senden, um einen entsprechenden Vorgang durchzuführen. Der Webserver 152 kann die Anfrage an einen oder mehrere entsprechende Anwendungsserver innerhalb der Anwendungsserverebene 154 weiterleiten, um eine oder mehrere entsprechende Anwendungen 160 aufzurufen. Die Anwendungsserverebene 154 kann einen oder mehrere Anwendungsserver enthalten, die Engines 140a, welche Prozess- und Dienstfunktionen des MDM-Systems 4 zur Verfügung stellen, die MDM-Benutzeroberfläche 140b und andere entsprechende Anwendungen 140 unterstützen. Die Anwendungsserverebene für Infrastrukturdienste 156 kann einen oder mehrere Anwendungsserver enthalten, die die Front-Side Datenzugriffsebene 42a, die Back-Side Datenzugriffsebene 42b und einen entsprechenden Arbeitsablauf-Controller auf Unternehmensebene 142 unterstützen, der Prozess- und Dienstfunktionen zur Verfügung stellt, die den Datenzugriffsebenen 42 zugeordnet sind. In einem bestimmten Ausführungsbeispiel kann z.B. die Front-Side Datenzugriffsebene 42a unter Verwendung eines WEBMETHODS ENTERPRISE SERVER-Produktes eingeführt werden, die Back-Side Datenzugriffsebene 42b kann teilweise unter Verwendung eines INFORMATICA POWERCENTER-Produktes mit integriertem Extract-Transform-Load-Tool (ETL) eingeführt werden, und der Arbeitsablauf-Controller auf Unternehmensebene 142 kann unter der Verwendung eines WEBMETHODS BUSINESS INTEGRATOR-Produktes eingeführt werden.
U einem Ausführungsbeispiel kann die Umsetzung von Prozessen 14 zwischen der Arbeitsablauf-Engine auf Unternehmensebene 162 der Anwendungsserverebene 156 und Anwendungen 160 der Anwendungsserverebene 154 aufgeteilt werden. Dienste 12 und zugeordnete Dienste 34 können hauptsächlich unter Verwendung der Anwendungsserverebene 154 zur Verfügung gestellt werden. Die Datenbankebene 158 enthält die tatsächlichen physischen Datenmodelle 114, wie z.B. das Referenzdatenmodell 114d und das Bereitstellungsdatenmodell 114e, die oben unter Bezugnahme auF 7 beschrieben wurden, mit zugeordneten Datendiensten, die entweder in der Datenbankebene 158 oder in der Anwendungsserverebene 154 zur Verfügung gestellt werden.
VII. Beispiel für einen Einführungsprozess für einen neuen Artikel
10 zeigt ein Beispiel eines Einführungsprozesses für einen neuen Artikel 14 im MDM-System 4. Obwohl die Einführung einer neuen Artikelentität für den Einzelhandel und die zugeordneten Verkäuferunternehmen als Beispiel beschrieben wird, ist die vorliegende Erfindung auf jede analoge oder andere Einführungen beliebiger geeigneter neuer Entitäten für jedes geeignete Unternehmen ausgerichtet, unabhängig davon, ob diese hier spezifisch beschrieben werden oder nicht.
Die Einführung neuer Artikel ist eine äußerst übliche und integrale Praktik für dynamische Wertschöpfungspartner, wie z.B. Einzelhändler oder Verkäufer gefertigter Waren. Die Häufigkeit, mit der neue Artikel in ein Einzelhandelssortiment eingeführt werden, kann abhängig vom Einzelhandelssegment und anderen Faktoren von einem bis hin zu tausend Fällen pro Woche variieren. Die Einführung eines neuen Artikels kann die wichtigste Phase im Lebenszyklus eines Artikels sein. Dieser Prozess war bisher mit viel Papierarbeit verbunden und hat Einzelhändlern und Verkäufern in der Fähigkeit zur Einführung von Artikeln auf einer dynamisch (d. h., von Tag zu Tag) Basis behindert, da bei der Einführung eines neuen Artikels Tausende von Variablen, Attributen und anderen Faktoren von der Preisauszeichnung bis zur Einsortierung in das Regal berücksichtigt werden müssen. Auf der Seite der Einzelhändler besteht der Bedarf, einen Großteil des Einführungsprozesses für neue Artikel zu automatisieren und die Integration in die Planung, Ausführung, Überwachung und andere Unternehmenslösungskomponenten zu rationalisieren, damit neue Artikel mit einer kürzeren Vorlaufzeit eingeführt, das Kundeninteresse geweckt und Marktanteile gewonnen werden können. In einem Ausführungsbeispiel mit einem Einführungsprozess für einen neuen Artikel 14 beinhaltet das MDM-System 4 einen eingebetteten Geschäftsablauf für die Einführung eines neuen Artikels, der ein Beispielhaftes Einzelhandelsunternehmens in die Lage versetzt, einen neuen Artikel schneller und einfacher, mit größerer Flexibilität und mit einer besseren Integration in die Planung, Ausführung, Überwachung und andere Unternehmenslösungskomponenten 6 einzuführen als mit früheren Techniken.
Ein neuer Artikel kann auf unterschiedliche Weisen eingeführt werden. Ein Verkäufer kann den neuen Artikel z.B. einem Einzelhändler vorstellen, ein Einzelhändler kann den neuen Artikel durch Artikeldesign (d.h. einen eigenen Produktnamen) einführen, oder ein Einzelhändler und ein Verkäufer können beschließen, gemeinsam einen neuen Artikel einzuführen. Zwar gibt es leichte Variationen in diesen drei Verfahren der Neuartikel-Einführung, jedoch konzentriert sich diese Beschreibung auf die internen Abläufe beim Einzelhändler und betrachtet deshalb die Einführung eines neuen Artikels aus allgemeiner Sicht. Das bedeutet, dass die beschriebenen Abläufe insofern allgemein sind, als dass sie die Prozesse, die der Einzelhändler ausführen kann, unabhängig davon umreißen, ob der Einzelhändler den neuen Artikel einführt, der Verkäufer den neuen Artikel einführt oder der Einzelhändler und der Verkäufer den neuen Artikel gemeinsam einführen. Diese Abläufe können auch auf alle Einzelhändlerformate (d.h. Großhändler, Kaufhaus usw.) und alle Handelssegmente (Verbrauchsgüter, Lebensmittel, Textilien usw.) angewendet werden.
Wie in 10 dargestellt, gibt es in einem Ausführungsbeispiel zwei Hauptaspekte für den Prozess zur Einführung eines neuen Artikels 14: (1) einen ersten Unterprozess 170, der die Einführung, Prüfung, Annahme und Ablehnung des neuen Artikels betrifft, was mit der Empfängnis eines Kindes gleichgesetzt werden kann; und (2) einen zweiten Unterprozess 172, der die Erstellung eines neuen Artikels beim Einzelhändler zur Initialisierung von Merchandising, Lagerauffüllung, Lieferkettenplanung und Ausführungsfunktionen für den neuen Artikel betrifft, um den neuen Artikel im Regal zum Verkauf an den Kunden verfügbar zu machen, was mit der Geburt eines Kindes gleichgesetzt werden kann. Der erste Unterprozess 170 kann ohne Einschränkung enthalten: eine Verkäufer-Einführungskomponente 174 (wobei der Verkäufer den neuen Artikel einführt), eine Einzelhändler-Prüfkomponente 176, eine Einzelhändler-Ablehnungs-/ Modifikationskomponente 178, eine Einzelhändler-Genehmigungskomponente 180 und eine Verkäufer-/Einzelhändler-Vertragsabschluss-Komponente 182. Der zweite Unterprozess 172 kann eine Verkäufer-/Einzelhändler-Verbindungskomponente 184 enthalten, in der der Verkäufer oder Einzelhändler geeignete Stammdaten für den neuen Artikel in der Datenbank 36 erstellt. Solche Stammdaten können z.B. Artikelstammdaten 186, Artikellokalisierungsstammdaten 188 und Verkäuferartikelstammdaten 190 enthalten. Nach der Erstellung und Speicherung der Stammdaten für den neuen Artikel entsprechend der Ausführung der Verkäufer/Einzelhändler-Verbindungskomponente 184 können bereits vorhandene Systeme 192 und zugeordnete Produktionsdatenbanken 194 des Einzelhändlers oder Verkäufers den neuen Artikel erhalten und für Merchandising, Lagerauffüllung, Lieferkettenplanung und Ausführungsfunktionen erkennen.
Bei der Bereitstellung von vollständig oder partiell automatisierten Prozessen 14 bei der Einführung, Eingabe, Erstellung und Wartung eines neuen Artikels kann es viele mögliche Vorteile geben. So kann z.B. die Automatisierung des Neuartikeleinführungsprozesses ohne Einschränkung einen oder mehrere der folgenden Vorteile zur Verfügung stellen: (1) Möglichkeit für den Einzelhändler, einen neuen Artikel schneller in sein Sortiment aufzunehmen und zu vertreiben, wodurch der neue Artikel dem Kunden schneller zugänglich gemacht wird als dies bei der Konkurrenz der Fall ist; (2) als Ergebnis einer kürzeren Vorlaufzeit für neue Artikel kann der Einzelhändler seine Chancen auf Verkaufssteigerung und größeren Marktanteil beträchtlich erhöhen; (3) geringere Arbeitskosten und weniger Papierarbeit innerhalb und zwischen den verschiedenen Einzelhandelsfunktionen; (4) Reduzierung oder Eliminierung der Möglichkeit von Verbindungsfehlern, wodurch das Potential menschlichen Versagens verringert wird; (5) engere und rationalisiertere Integration des Neuartikeleinfiihrungsprozesses in die Planung, Ausführung, Überwachung oder andere Unternehmenslösungskomponenten 6, was zu besserer Platzierung und Lagerauffüllung von Waren führt; und (6) effizientere Planung und Ausführung, die durch rationalisierte Integration in die Einführung neuer Artikel erreicht wird und effektiv eingestellt werden kann, um dem Endverbraucher den günstigsten Endpreis zur Verfügung stellen zu können. Hinsichtlich engerer und rationalisierterer Integration können Beispiele ohne Einschränkung enthalten: (1) Daten von einem Verkäuferangebot zu dem neuen Artikel können automatisch für den Einzelhändler eingetragen und müssen nicht mehr manuell eingegeben werden, damit ein Vertrag hinsichtlich des neuen Artikels abgeschlossen werden kann; (2) eine universelle Produktnummer (UPC) kann automatisch für einen neuen Artikel erstellt werden, sobald der neue Artikel erstellt wurde, und muss nicht mehr manuell eingegeben werden; (3) ein älteres Einzelhändlersystem kann automatisch geprüft werden, wenn sichergestellt werden soll, dass eine UPC-Nummer eines neuen Artikels einer Einzelhändlerproduktnummer zugeordnet ist, und muss nicht mehr manuell verifiziert werden; und (4) in einem Merchandising-Planungssystem oder in anderen Unternehmenslösungskomponenten 6 kann eine Produktnummer für ein neues Produkt automatisch für die Erzeugung eines Produktsortiments eingegeben werden, das einen neuen Artikel einschließt, und muss nicht mehr manuell eingegeben werden.
Der in 10 dargestellte Einführungsprozess für einen neuen Artikel 14 kann detaillierter beschrieben werden, von der Einführung des neuen Artikels durch den Verkäufer bis hin zur Wartung des Artikels durch den Einzelhändler in seinen Systemen. In einem Ausführungsbeispiel kann die Einführung, Eingabe, Erstellung und Wartung eines neuen Artikels, die dem Einführungsprozess für einen neuen Artikels 14 bei einem Beispieleinzelhändler zugeordnet ist, ohne Einschränkung in die folgenden primären Unterprozesse gegliedert werden: (1) einen Unterprozess für die Initiierung; (2) einen Unterprozess für die vorläufige Planung; (3) einen Unterprozess für die Artikeleingabe, Bestätigung, erste Schätzung und Lagerauffüllungsinitiierung; (4) einen Unterprozess für die Einrichtung, Erstellung und Aktivierung des Artikels und für die erste Lagerauffüllung; (5) einen Unterprozess für Artikel-Merchandising und Regalauffüllung; (6) einen Unterprozess für die Artikelvorhersageeingabe und Auffüllung; (7) einen Unterprozess für die Auftragsverwaltung und Kollaboration; (8) Unterprozesse für eingehende (Verkäufer an Einzelhändler) und ausgehende (Einzelhändler an On) Lieferkettenverwaltung und Ausführung; (9) einen Unterprozess für die Artikelwartung; und (10) einen Unterprozess für die Handhabung und Verwaltung von Ausnahmen.
Obwohl die vorliegende Erfindung in mehreren Ausführungsbeispielen beschrieben wurde, werden Fachleute auf diesem Gebiet eine Fülle von Änderungen, Ersetzungen, Variationen, Anpassungen und Ausführungen vorschlagen, und es ist beabsichtigt, dass die Erfindung all diese Änderungen, Ersetzungen, Variationen, Anpassungen und Ausführungen umfasst, die innerhalb des Umfangs der im Anhang aufgeführten Ansprüche liegen.

Claims

System zur zentralen Verwaltung von Kernunternehmensreferenzdaten, die einem Unternehmen zugeordnet sind, aufweisend: ein zentralisiertes Stammdepot, das die Kernunternehmensreferenzdaten enthält; ein internes Dienstegefüge, das mit dem zentralisierten Stammdepot verbunden ist und interne Dienste für die Verwaltung der Kernunternehmensreferenzdaten im zentralisierten Stammdepot zur Verfügung stellt, wobei ein oder mehrere der interne Dienste direkten Zugriff auf die Kernunternehmensreferenzdaten haben, die zu Verwaltungszwecken im zentralisierten Stammdepot gespeichert werden; und eine Infrastrukturdiensteebene, die mit dem zentralisierten Stammdepot verbunden ist und die Massendatentransfers von Kernunternehmensreferenzdaten zwischen dem zentralisierten Stammdepot und einem oder mehreren externen Betriebssystemen gemäß einem oder mehreren Geschäftsabläufen auf Unternehmensebene zur Verfügung stellt, wobei den externen Betriebssysteme für betriebliche Zwecke indirekter Zugriff auf die im zentralisierten Stammdepot gespeicherten Kernunternehmensreferenzdaten gestattet ist.
System nach Anspruch 1, wobei das System ein sicheres Aufzeichnungssystem aufweist, dessen Architektur und Design für die Verwaltung von Kernunternehmensreferenzdaten und nicht für die betriebliche Verwendung von Kernunternehmensreferenzdaten durch die externen Betriebssysteme optimiert sind.
System nach Anspruch 1, wobei ein externer Zugriffsdienst einen Mechanismus zur Verfügung stellt, der es erlaubt, die Kernunternehmensreferenzdaten im zentralisierten Stammdepot in den beständigen Speichern der externen Betriebssysteme für die betriebliche Verwendung durch die externen Betriebssysteme nachzubilden, wobei den externen Betriebssysteme kein direkter Zugriff auf die Kernunternehmensreferenzdaten im zentralisierten Stammdepot gestattet ist.
System nach Anspruch 1, wobei die Bereitstellung von zentralisierter Speicherung und Verwaltung der Kernunternehmensreferenzdaten im zentralisierten Stammdepot die Modifizierung eines externen Betriebssystems ermöglicht, ohne dass die Kernunternehmensreferenzdaten im zentralisierten Stammdepot modifiziert werden müssen.
System nach Anspruch 1, wobei die Bereitstellung von zentralisierter Speicherung und Verwaltung der Kernunternehmensreferenzdaten im zentralisierten Stammdepot die Integration eines externen Betriebssystems ermöglicht, wenn das externe Betriebssystem eingeführt, modifiziert oder ersetzt wird.
System nach Anspruch 1, wobei die Bereitstellung von zentralisierter Speicherung und Verwaltung der Kernunternehmensreferenzdaten im zentralisierten Stammdepot die Integration eines anderen Unternehmens in das Unternehmen ermöglicht.
System nach Anspruch 1, das eine Datenbank aufweist, aufweisend: einen Bereich für verwaltete Daten, der das zentralisierte Stammdepot zur Verfügung stellt, das die Kernunternehmensreferenzdaten enthält; einen Bereich für zwischengespeicherte Daten, der einem oder mehreren der internen Dienste direkten Zugriff auf die Kernunternehmensreferenzdaten zur Verfügung stellt, wobei der Bereich für zwischengespeicherte Daten zwischengespeicherte Daten enthält, die Kernunternehmensreferenzdaten repräsentieren, die zur Verarbeitung im Zusammenhang mit dem einen oder den mehreren internen Diensten aus dem Bereich für verwaltete Daten extrahiert und nach solch einer Verarbeitung wieder in den Bereich für verwaltete Daten eingefügt wurden; und einem Betriebszugriffsbereich, der den externen Betriebssystemen indirekten Zugriff auf die Kernunternehmensreferenzdaten zur Verfügung stellt, wobei der Betriebszugriffsbereich einen Bereitstellungsbereich für Kernunternehmensreferenzdaten enthält, die zwischen dem Bereich für verwaltete Daten und den externen Betriebssystemen zugeordneten beständigen Datenspeichern übertragen werden.
System nach Anspruch 7, wobei: der Bereich für zwischengespeicherte Daten einen Mechanismus zur Verfügung stellt, der eine Kopie von Kernunternehmensreferenzdaten als zwischengespeicherte Daten in einem vorübergehenden Status zurückhält, so dass sie gemäß einem Manipulationsvorgang manipuliert werden können; und die Kernunternehmensreferenzdaten im Bereich für verwaltete Daten im tatsächlichen Status zum Nur-Lesezugriff gesperrt bleiben, bis der Manipulationsvorgang abgeschlossen ist, wobei der Manipulationsvorgang über den vorübergehenden Status der zwischengespeicherten Daten im Bereich für zwischengespeicherte Daten informiert ist und den noch nicht abgeschlossenen Manipulationsvorgang und nicht den tatsächlichen Status der Kernunternehmensreferenzdaten im Bereich für verwaltete Daten widerspiegelt, wobei andere dem System zugeordnete Prozesse über den tatsächlichen Status der Kernunternehmensreferenzdaten im Bereich für verwaltete Daten und nicht den vorübergehenden Status der zwischengespeicherten Daten im Bereich fur zwischengespeicherte Daten informiert sind, der den noch nicht abgeschlossenen Manipulationsvorgang widerspiegelt.
System nach Anspruch 1, das eine Datenbank aufweist, aufweisend: einen Bereich für verwaltete Daten, der das zentralisierte Stammdepot zur Verfügung stellt, das die Kernunternehmensreferenzdaten enthält; einen Bereitstellungsbereich für eingehende Daten für die temporäre Speicherung und Verarbeitung von eingehenden Kernunternehmensreferenzdaten erhaltenen aus einer oder mehreren Datenquellen vor dem Laden der eingehenden Kernunternehmensreferenzdaten in den Bereich für verwaltete Daten; und einen Bereitstellungsbereich für ausgehende Daten für die temporäre Speicherung und Verarbeitung von ausgehenden Kernunternehmensreferenzdaten extrahiert aus dem Bereich für verwaltete Daten vor der Übertragung der ausgehenden Kernunternehmensreferenzdaten an ein oder mehrere Datenziele.
System nach Anspruch 9, wobei die Kernunternehmensreferenzdaten im Bereich für verwaltete Daten im Wesentlichen kontinuierlich mit den ausgehenden Kernunternehmensreferenzdaten im Bereitstellungsbereich für ausgehende Daten synchronisiert werden, so dass im Bereitstellungsbereich für ausgehende Daten zu jedem Zeitpunkt eine genaue Übersicht über die Kernunternehmensreferenzdaten im Bereich für verwaltete Daten zur Verfügung steht.
System nach Anspruch 10, wobei: ausgehende Kernunternehmensreferenzdaten Betriebsdaten aufweisen, die für externe Betriebssysteme bestimmt sind; und Synchronisierung der Betriebsdaten im Bereitstellungsbereich für ausgehende Daten mit den Kernunternehmensreferenzdaten im Bereich für verwaltete Daten dabei hilft, sicherzustellen, dass Planung basierend auf den Betriebsdaten nicht ausgeführt wird für eine Entität, die im Unternehmen nicht mehr so existiert wie in den Kernunternehmensreferenzdaten im Bereich für verwaltete Daten dargestellt.
System nach Anspruch 9, wobei der Bereich für ausgehende Daten aufweist: eine oder mehrere verbundene Bereitstellungstabellen für ausgehende Daten zur temporären Speicherung und Verarbeitung von ausgehenden Kernunternehmensreferenzdaten, die vor der Übertragung der ausgehenden Kernunternehmensreferenzdaten an ein oder mehrere Datenziele aus dem Bereich für verwaltete Daten extrahiert wurden; und eine oder mehrere unverbundene Bereitstellungstabellen für ausgehende Daten zur temporären Speicherung und Verarbeitung von ausgehenden Daten, die aus dem Bereitstellungsbereich für eingehende Daten entgegengenommen werden, aber nicht vor der Übertragung der ausgehenden Daten an ein oder mehrere Datenziele in den Bereich für verwaltete Daten geladen werden dürfen.
System nach Anspruch 1, das eine relationale Datenbank aufweist, die das zentralisierte Stammdepot enthält, wobei die relationale Datenbank ein Kernreferenzdatenmodell aufweist, das über ein zugeordnetes physisches Schema verfügt, wobei vorhandene dem physischen Schema unter Verwendung einer objektbezogene Zuweisungsebene zugewiesen sind.
System nach Anspruch 1, das eine relationale Datenbank aufweist, die das zentralisierte Stammdepot enthält, wobei die relationale Datenbank ein festes Kernreferenzdatenmodell aufweist, das über ein zugeordnetes festes physisches Schema verfügt, wobei eine niedrige Zugriffsebene beständige Objekte zur Verfügung stellt, die auf das feste physische Schema zugeschnitten sind, wobei neue objektorientierte interne Dienste unter Verwendung der spezifisch zugeschnittenen niedrigen Zugriffsebene dem festen physischen Schema zugewiesen werden.
System nach Anspruch 1, wobei das zentralisierte Stammdepot viele Stammdepots aufweist, die an vielen physischen Orten liegen, wobei das zentralisierte Stammdepot gegenüber internen Diensten und externen Betriebssystemen als ein einzelnes Stammdepot an einem einzelnen physischen Ort erscheint.
System nach Anspruch 1, das eine Datenbank aufweist, die zumindest einige der Kernuntemehmensreferenzdaten im zentralisierten Stammdepot enthält, wobei sämtliche Kernunternehmensreferenzdaten, die nicht physisch in der Datenbank enthalten sind, gegenüber internen Diensten und externen so erscheinen, als ob sie physisch in der Datenbank enthalten wären.
System nach Anspruch 1, wobei das zentralisierte Stammdepot ein multidimensionales Datenbankkonstrukt einschließt, in dem alle im zentralisierten Stammdepot gespeicherten Kernunternehmensreferenzdaten als ein Attribut dargestellt werden, das einem Punkt in einem n-dimensionalen Entitätenraum zugeordnet ist.
System nach Anspruch 17, wobei: die Kernunternehmensreferenzdaten Stammdaten aufweisen, die Kernkonfigurationsdaten repräsentieren, die Entitäten des Unternehmens zugeordnet sind; und ein Stamm einer Entität der Entität zugeordnete Stammdaten auf dimensionale Weise so erstellen, manipulieren, navigieren, sichten und extrahieren kann, dass der eine oder mehrere Geschäftsabläufe auf Unternehmensebene unterstützt werden.
System nach Anspruch 1, das eine Datenbank aufweist, die: das zentralisierte Stammdepot enthält; und ein konsistentes dimensionales Modellgefüge einschließt, das auf ein Modell angewendet wird, das einen Beständigkeits-Verwaltungsdienst unterstützt und es so erlaubt, dass Kernunternehmensreferenzdaten konsistent mit etablierten dimensionalen Ansichten der Kernunternehmensreferenzdaten verwaltet werden können.
System nach Anspruch 1, wobei die Kernunternehmensreferenzdaten Stammdaten aufweisen und das System ein Stammdaten-Verwaltungssystem aufweist.
System nach Anspruch 1, wobei der interne Dienstegefüge ein Geschäftsprozess-Toolkit aufweist, mit dem dem System zugeordnete Modelle verwaltet werden können, wobei das Geschäftsprozess-Toolkit aufweist: eine Modellbibliothek, die Datenmodelle enthält; und einen oder mehrere Modellierungsdienste zum Modellieren des Systems, seiner Struktur und seiner Bestandteile.
System nach Anspruch 21, wobei die Modelle ein oder mehrere Prozessmodelle aufweisen, die Prozesse beschreiben, die zur Verwaltung der im zentralisierten Stammdepot gespeicherten Kernunternehmensreferenzdaten verwendet werden, wobei jedes Prozessmodell für einen entsprechenden Prozess die Aufgabenabfolge beschreibt, die im Zusammenhang mit dem Prozess auf die Kernunternehmensreferenzdaten angewendet wird, wobei einer oder mehrere bestimmte interne mit diesen Aufgaben in Zusammenhang stehen, und einer oder mehrere bestimmte Prozess-Engines für die Ausführung des Prozesses verantwortlich sind.
System nach Anspruch 21, wobei die Modelle aufweisen: ein Dokumentenmodell, das Metadaten für Dokumente zur Verfügung stellt, die im Zusammenhang mit den Prozessen verwendet werden, die für die Verwaltung der im zentralisierten Stammdepot gespeicherten Kernunternehmensreferenzdaten zuständig sind, wobei jedes Dokument eine Darstellung eines Metadatenelements innerhalb eines zugrunde liegenden Kernunternehmensreferenzdatenmodells zur Verfügung stellt; ein Formenmodell, das Metadaten zur Verfügung stellt, die Formen beschreiben, die Objekten im zugrunde liegenden Kernunternehmensreferenzdatenmodell zugeordnet sind; und ein Kernunternehmensreferenzdatenmodell, das Metadaten darstellt, die die im zentralisierten Stammdepot gespeicherten Kernunternehmensreferenzdaten beschreiben, wobei Änderungen an dem Kernunternehmensreferenzdatenmodell in der Lage sind, so in den Formen- und Dokumentenmodellen widergespiegelt zu werden, dass diese Modelle mit dem Kernunternehmensreferenzdatenmodell synchronisiert werden.
System nach Anspruch 23, wobei das interne Dienstegefüge in der Lage ist, die Formen- und Dokumentenmodelle als Reaktion auf Änderungen am Kernunternehmensreferenzdatenmodell automatisch mit dem Kernunternehmensreferenzdatenmodell zu synchronisieren.
System nach Anspruch 21, wobei die Modelle ein Kernunternehmensreferenzdatenmodell aufweisen, das Metadaten repräsentiert, die die Kernunternehmensreferenzdaten beschreiben, die im zentralisierten Stammdepot gespeichert sind.
System nach Anspruch 25, wobei das Kernunternehmensreferenzdatenmodell ein Unternehmensmetamodell im Format Extensible Markup Language (XML) Software Description Format (XSD) aufweist, das die Metadaten von Instanzdaten trennt, um die Verwaltung von Metadaten zu ermöglichen, und das es einer Datenzugriffsebene in der Infrastrukturdiensteebene erlaubt, die Metadaten direkt aus der Modellbibliothek zu lesen.
System nach Anspruch 25, wobei das Kernunternehmensreferenzdatenmodell ein generisches Kernunternehmensreferenzdatenmodell aufweist, das eine Synthese von Datenelementen darstellt, die für eine Vielzahl von tatsächlichen Umsetzungen des Systems anwendbar sind, und das eine Obermenge von tatsächlichen Kernunternehmensreferenzdatenmodellen für die Verwendung in einer Vielzahl von tatsächlichen Umsetzungen des Systems aufweist, wobei jedes dieser tatsächlichen Kernunternehmensreferenzdatenmnodelle vom generischen Kernunternehmensreferenzdatenmodell abgeleitet werden kann.
System nach Anspruch 21, wobei das Modell aufweist: ein Kernunternehmensreferenzdatenmodell, das Metadaten darstellt, die die im zentralisierten Stammdepot gespeicherten Kernunternehmensreferenzdaten beschreiben; und ein Bereitstellungsdatenmodell, das Metadaten darstellt, die die Strukturen von Bereitstellungstabellen für ein- und ausgehende Daten einer Datenbank, die das zentralisierte Stammdepot zur Verfügung stellt, beschreiben, und das Zuweisungen zwischen dem Kernunternehmensreferenzdatenmodell und einer Darstellung von Daten in den Bereitstellungstabellen für ein- und ausgehende Daten in Bereitstellungstabellen zur Verfügung stellt, wobei die Zuweisungen aufweisen: für eingehende Daten eine Zuweisung des Kernunternehmensreferenzdatenmodells zu einem Bereitstellungsdatenmodell für eingehende Daten, das ein beliebiges Eingangsdatenformat für ein externes Betriebssystem darstellt, wobei die Zuweisung ausgeführt wird, wenn eingehende Daten im zentralisierten Stammdepot als Kernunternehmensreferenzdaten gespeichert werden; und für ausgehende Daten eine Zuweisung des Kernunternehmensreferenzdatenmodells zu einem Bereitstellungsdatenmodell für ausgehende Daten, das eine flaches Ausgabedatenformat für ein externes Betriebssystem darstellt, wobei die Zuweisung ausgeführt wird, wenn Kernunternehmensreferenzdaten als ausgehende Daten aus dem zentralisierten Stammdepot verschoben werden.
System nach Anspruch 21, wobei die Modellierung eines oder aufweist aus: Modellieren struktureler Aspekte einer Datenbank, die das zentralisierte Stammdepot zur Verfügung stellt; und Modellieren von einem oder mehreren Geschäftsabläufen auf Unternehmensebene.
System nach Anspruch 21, wobei ein oder mehrere Modellierungsdienste einen Strukturaktualisierungsdienst aufweisen, der einen Mechanismus zur Verfügung stellt, mit dem ein Strukturmodell erstellt oder modifiziert und in Reaktion darauf das erstellte oder modifizierte Strukturmodell automatisch in eine tatsächliche Umsetzung des Systems integriert werden kann.
System nach Anspruch 1, wobei das interne Dienstegefüge einen oder mehrere aufweist aus: Datensicherheitsdienste, die Authentifizierungs- und Autorisierungsdienste aufweisen; allgemeine Datendienste, die Änderungsverwaltung, Lebenszyklusverwaltung, Gruppenverwaltung und Analyse- und Berichtsdienste aufweisen; Datenzugriffsdienste, die Beständigkeitsverwaltungs- und Datenzugriffsebenendienste aufweisen; und Datenbereitstellungsdienste, die Datenimport-, Überprüfungs- und Syndizierungsdienste aufweisen.
System nach Anspruch 1, wobei die Infrastrukturdiensteebene eine Back-Side Datenzugriffsebene aufweist, die in der Lage ist um: externen Betriebssystemen indirekten Zugriff auf zugeordnete externe Betriebsdienste innerhalb des Systems bereitzustellen, die indirekt über einen oder mehrere dem zentralisierten Kerndepot zugewiesene Bereitstellungsbereiche auf die Kernunternehmensreferenzdaten innerhalb des zentralisierten Kerndepots zugreifen; Massendatentransfers von Kernunternehmensreferenzdaten zwischen dem zentralisierten Stammdepot und den externen Betriebssystemen bereitzustellen; und Datenintegration in die externen Betriebssysteme zu ermöglichen.
System nach Anspruch 1, wobei die Infrastrukturdiensteebene auch die Mitteilungsübermittlung innerhalb des Unternehmens zwischen einem oder mehreren internen Diensten und den externen Betriebssystemen entsprechend der Vorgehensweise eines oder mehrerer Geschäftsabläufe auf Unternehmensebene zur Verfügung stellt.
System nach Anspruch 1, wobei die Infrastrukturdiensteebene eine Front-Side Datenzugriffsebene aufweist, die in der Lage ist um: externe Betriebssysteme direkten Zugriff auf bestimmte interne Dienste bereitzustellen, die direkt auf die Kernunternehmensreferenzdaten im zentralisierten Kerndepot zugreifen; Kontrolldaten von den externen Betriebssystemen an das System zu übertragen, um Vorgänge des Systems zu kontrollieren; und Integration von Anwendungen in die externen Betriebssysteme zu ermöglichen.
System nach Anspruch 34, wobei die Front-Side Datenzugriffsebene unter Verwendung einer objektbasierten Diensteebene verkörpert ist, die auf dem Anwendungsserver in einer Anwendungsserverebene liegt.
System nach Anspruch 1, wobei die Infrastrukturdiensteebene aufweist: eine Back-Side Datenzugriffsebene, die dazu in der Lage ist, Massendatentransfer von Kernunternehmensreferenzdaten zwischen dem zentralisierten Stammdepot und den externen Betriebssystemen zur Verfügung zu stellen; und eine Front-Side Datenzugriffsebene, die in der Lage ist um: Kontrolldaten von den externen Betriebssystemen an das System zu übertragen, um Systemvorgänge zu kontrollieren; und Kernunternehmensreferenzdaten zwischen dem zentralisierten Stammdepot und einem externen Betriebssystem zu übertragen, wobei das externe Betriebssystem Kernunternehmensreferenzdaten in einem bestimmten Format benötigt, das die Back-Side Datenzugriffsebene nicht unterstützt.
System nach Anspruch 1, das aufweist: eine logische Prozessebene, die einen Kontext für die Einführung und vollständige oder partielle Automatisierung von Geschäftskonfigurationsprozessen zur Verfügung stellt, die einem oder mehreren Geschäftsabläufen auf Unternehmensebene zugeordnet sind; eine logische Dienstebene, die der logischen Prozessebene zugrunde liegt und Dienstfunktionen zur Verfügung stellt, die Prozessaufgaben für die automatisierten Geschäftskonfigurationsprozesse ermöglichen; und eine logische Datenebene, die der logischen Dienstebene zugrunde liegt und grundlegende Datenmodelle und physische Darstellungen zum Speichern der Kernunternehmensreferenzdaten zur Gewinnung und Verwendung im Zusammenhang mit den Geschäftskonfigurationsprozessen und Dienstfunktionen zur Verfügung stellt.
System nach Anspruch 1, wobei einer oder mehrere der Geschäftsabläufe auf Unternehmensebene in das System eingebettet sind und unter Verwendung einer Arbeitsablauf-Engine auf Unternehmensebene zur vollständigen oder partiellen Automatisierung eines oder mehrerer zugeordneter Geschäftsprozesse auf Unternehmensebene vollständig oder partiell automatisiert sind.
System nach Anspruch 38, wobei ein automatisierter Geschäftsablauf auf Unternehmensebene einen Einführungsprozess für eine neue Entität aufweist.
System nach Anspruch 39, wobei der automatisierte Einführungsprozess für eine neue Entität ein automatisierter Einführungsprozess für einen neuen Artikel in einem Einzelhandelsunternehmen ist, wobei der automatisierte Einführungsprozess für einen neuen Artikel aufweist hinzufügen von neuen Kernunternehmensreferenzdaten für den neuen Artikel zum zentralisierten Stammdepot, überprüfen der neuen Kernunternehmensreferenzdaten für den neuen Artikel, der Verwendung des neuen Artikels zustimmen und den neuen Artikels als verfügbar zur Verwendung durch die externen Betriebssysteme zu veröffentlichen.
System nach Anspruch 40, wobei der neue Artikel als verfügbar für die Verwendung durch die externen Betriebssysteme durch Nachbildung für die interne Verwendung durch externe Betriebssysteme und nicht für direkten Zugriff auf den neuen Artikel innerhalb des zentralisierten Stammdepots durch die externen Betriebssysteme veröffentlicht wird.
System nach Anspruch 40, wobei der automatisierte Einführungsprozess für einen neuen Artikel aufweist: erzeugen und speichern eines oder mehrerer Stämme für den neuen Artikel innerhalb des zentralisierten Stammdepots; und die externen Betriebssysteme erhalten und erkennen den neuen Artikel für Merchandising, Lagerauffüllung und Lieferkettenplanungs- und – ausführungsvorgänge.
System nach Anspruch 42, wobei der eine oder die mehreren Stämme für den neuen Artikel einen Artikelstamm, einen Artikelortstamm und einen Verkäuferartikelstamm aufweisen.
System nach Anspruch 40, wobei der automatisierte Einführungsprozess für einen neuen Artikel rationalisierte Integration in externe Betriebssysteme zur Verfügung stellt, welche Merchandising, Lagerauffüllung und Lieferkettenplanungs- und -ausführungsvorgänge in Bezug auf den neuen Artikel zur Verfügung stellen.
System nach Anspruch 44, wobei die rationalisierte Integration eines oder mehrere aufweist aus: Daten aus einem Verkäuferangebot, das dem neuen Artikel automatisch zugeordnet ist, werden automatisch eingetragen und müssen nicht manuell eingegeben werden, um einen Vertrag im Hinblick auf den neuen Artikel abzuschließen, eine universelle Produktnummer (UPC) wird automatisch für den neuen Artikel erstellt, sobald der neue Artikel erstellt ist, und muss nicht mehr manuell eingegeben werden; ein bereits vorhandenes System des Einzelhändlers wird automatisch überprüft, so dass sichergestellt werden kann, dass die universelle Produktnummer für den neuen Artikel einer Einzelhändlerproduktnummer zugeordnet ist, und muss nicht mehr manuell überprüft werden; und eine Einzelhändlerproduktnummer für ein neues Produkt wird automatisch für die Erstellung eines Produktsortiments eingetragen, das den neuen Artikel einschließt, und muss nicht mehr manuell eingegeben werden.
System nach Anspruch 1, wobei: ein Unternehmenslösungsgefüge für das Unternehmen aufweist: ein Konfigurationssegment, das eine Konfiguration des Unternehmens spezifiziert; ein Planungssegment zur Planung hinsichtlich des Unternehmens und seiner Entitäten entsprechend der im Konfigurationssegment spezifizierten Konfiguration des Unternehmens, wobei Planung die Erzeugung von Entscheidungen aufweist, die Aktionen spezifizieren, die durchzuführen sind; ein Ausführungssegment zur Ausführung hinsichtlich des Unternehmens und seiner Entitäten entsprechend dem Ergebnis des Planungssegmentes, wobei die Ausführung das Durchführen von Aktionen aufweist, die auf den im Planungssegment getroffenen Entscheidungen basieren; und ein Überwachungssegment zur Überwachung hinsichtlich des Unternehmens und seiner Entitäten entsprechend dem Ergebnis des Ausführungssegments, wobei die Überwachung die Bestimmung von Ergebnissen von Aktionen, die im Ausführungssegment durchgeführt wurden, sowie das Bereitstellen von Feedback bezüglich der Konfigurations- und Planungssegmente aufweist; das System das Konfigurationssegment verkörpert; und eine Vielzahl externer Betriebssysteme die Planungs-, Ausführungs- und Überwachungssegmente verkörpern.
System nach Anspruch 1, wobei jedes von einem oder mehreren externen Betriebssystemen aufweist: ein Planungssystem; ein Ausführungssystem; oder ein Überwachungssystem.
System nach Anspruch 47, wobei es sich bei dem Unternehmen um ein Einzelhandelsunternehmen handelt und die externen Betriebssysteme aufweisen: ein Merchandising-Planungssystem; ein Ergänzungsplanungssystem; ein Auftragsverwaltungssystem; und ein Logistik- und Vertriebssystem.
System nach Anspruch 1, wobei die externen Betriebssysteme eines oder mehrere aufweisen aus: externe Unternehmenslösungskomponenten, die dem Unternehmen zugeordnet sind; und externe Unternehmen.
Verfahren zur zentralen Verwaltung von Kernunternehmensreferenzdaten, die einem Unternehmen zugeordnet sind, aufweisend: warten eines zentralisierten Stammdepots, das die Kernunternehmensreferenzdaten enthält; verwenden eines internen Dienstegefüges, das mit dem zentralisierten Stammdepot verbunden ist und interne Dienste für die Verwaltung der Kernunternehmensreferenzdaten im zentralisierten Stammdepot zur Verfügung stellt, wobei einem oder mehreren der internen Dienste direkter Zugriff auf die Kernunternehmensreferenzdaten zur Verfügung gestellt wird, die für Verwaltungszwecke im zentralisierten Stammdepot gespeichert sind; und verwenden einer Infrastrukturdienstebene, die mit dem zentralisierten Stammdepot verbunden ist und Massendatentransfers von Kernunternehmensreferenzdaten zwischen dem zentralisierten Stammdepot und einem oder mehreren externen Betriebssystemen gemäß einem oder mehrerer Arbeitsabläufe auf Unternehmensebene zur Verfügung stellt, wobei den externen Betriebssystemen indirekter Zugriff auf die Kernunternehmensreferenzdaten zur Verfügung gestellt wird, die für Betriebszwecke im zentralisierten Stammdepot gespeichert sind.
Verfahren nach Anspruch 50, wobei das zentralisierte Stammdepot ein sicheres Aufzeichnungssystem aufweist, das in Architektur und Design für die Verwaltung von Kernunternehmensreferenzdaten und nicht für betriebliche Verwendung der Kernunternehmensreferenzdaten durch die externen Betriebssysteme optimiert ist.
Verfahren nach Anspruch 50, das weiterhin aufweist verwenden eines externen Zugriffsdienstes, der erlaubt, daß die Kernunternehmensreferenzdaten im zentralisierten Stammdepot in beständigen Speichern der externen Betriebssysteme für betriebliche Verwendung durch die externen Betriebssysteme nachgebildet werden, wobei den externen Betriebssysteme direkter Zugriff auf die Kernunternehmensreferenzdaten im zentralisierten Stammdepot nicht gestattet ist.
Verfahren nach Anspruch 50, wobei bereitstellen zentralisierter Speicherung und Verwaltung der Kernunternehmensreferenzdaten im zentralisierten Stammdepot die Anpassung eines externen Betriebssystems ermöglicht, ohne daß dafür die Kernunternehmensreferenzdaten im zentralisierten Stammdepot angepasst werden müssen.
Verfahren nach Anspruch 50, wobei bereitstellen zentralisierter Speicherung und Verwaltung von Kernunternehmensreferenzdaten im zentralisierten Stammdepot die Integration eines externen Betritebssystems ermöglicht, wenn das externe Betriebssystem eingeführt, modifiziert oder ersetzt wird.
Verfahren nach Anspruch 50, wobei bereitstellen von zentralisierter Speicherung und Verwaltung der Kernunternehmensreferenzdaten im zentralisierten Stammdepot die Integration eines anderen Unternehmens in das Unternehmen ermöglicht.
Verfahren nach Anspruch 50, der weiterhin aufweist warten einer Datenbank, aufweisend: einen Bereich für verwaltete Daten, der das zentralisierte Stammdepot zur Verfügung stellt, das die Kernunternehmensreferenzdaten enthält; einen Bereich für zwischengespeicherte Daten, der einem oder mehreren der internen Dienste direkten Zugriff auf die Kernunternehmensreferenzdaten zur Verfügung stellt, wobei der Bereich für zwischengespeicherte Daten zwischengespeicherte Daten enthält, die Kernunternehmensreferenzdaten repräsentieren, die zur Verarbeitung im Zusammenhang mit dem einem oder den mehreren internen Diensten aus dem Bereich für verwaltete Daten extrahiert und nach solch einer Verarbeitung wieder in den Bereich für verwaltete Daten eingefügt wurden; und einem Betriebszugriffsbereich, der den externen Betriebssystemen indirekten Zugriff auf die Kernunternehmensreferenzdaten zur Verfügung stellt, wobei der Betriebszugriffsbereich einen Bereitstellungsbereich für Kernunternehmensreferenzdaten enthält, die zwischen dem Bereich für verwaltete Daten und den externen Betriebssystemen zugeordneten beständigen Datenspeichern übertragen werden.
Verfahren nach Anspruch 56, wobei: der Bereich für zwischengespeicherte Daten einen Mechanismus zur Verfügung stellt, der eine Kopie von Kernunternehmensreferenzdaten als zwischengespeicherte Daten in einem vorübergehenden Status zur Manipulation gemäß einem Manipulationsvorgang zurückbehält; und die Kernunternehmensreferenzdaten im Bereich für verwaltete Daten im tatsächlichen Status zum Nur-Lesezugriff gesperrt bleiben, bis der Manipulationsvorgang abgeschlossen ist, wobei der Manipulationsvorgang über den vorübergehenden Status der zwischengespeicherten Daten im Bereich für zwischengespeicherte Daten informiert ist und den noch nicht abgeschlossenen Manipulationsvorgang und nicht den tatsächlichen Status der Kernunternehmensreferenzdaten im Bereich für verwaltete Daten widerspiegelt, wobei andere Prozesse über den tatsächlichen Status der Kernunternehmensreferenzdaten im Bereich für verwaltete Daten informiert sind und nicht den vorübergehenden Status der zwischengespeicherten Daten im Bereich für zwischengespeicherte Daten sehen, der den noch nicht abgeschlossenen Manipulationsvorgang widerspiegelt.
Verfahren nach Anspruch 50, das weiterhin aufweist verwalten einer Datenbank, aufweisend: einen Bereich für verwaltete Daten, der das zentralisierte Stammdepot zur Verfügung stellt, das die Kernunternehmensreferenzdaten enthält; einen Bereitstellungsbereich für eingehende Daten für temporäre Speicherung und Verarbeitung von eingehenden Kernunternehmensreferenzdaten erhaltenen aus einer oder mehreren Datenquellen vor dem Laden der eingehenden Kernunternehmensreferenzdaten in den Bereich für verwaltete Daten; und einen Bereitstellungsbereich für ausgehende Daten für temporäre Speicherung und Verarbeitung von ausgehenden Kernunternehmensreferenzdaten extrahiert aus dem Bereich für verwaltete Daten vor der Übertragung der ausgehenden Kernunternehmensreferenzdaten an ein oder mehrere Datenziele.
Verfahren nach Anspruch 58, wobei die Kernunternehmensreferenzdaten im Bereich für verwaltete Daten im Wesentlichen kontinuierlich mit den ausgehenden Kernunternehmensreferenzdaten im Bereitstellungsbereich für ausgehende Daten synchronisiert werden, so dass im Bereitstellungsbereich für ausgehende Daten zu jedem Zeitpunkt eine genaue Übersicht über die Kernunternehmensreferenzdaten im Bereich für verwaltete Daten zur Verfügung steht.
Verfahren nach Anspruch 59, wobei: ausgehende Kernunternehmensreferenzdaten Betriebsdaten aufweisen, die für externe Betriebssysteme bestimmt sind; und Synchronisierung der Betriebsdaten im Bereitstellungsbereich für ausgehende Daten mit den Kernunternehmensreferenzdaten im Bereich für verwaltete Daten dabei hilft, sicherzustellen, dass Planung basierend auf den Betriebsdaten nicht ausgeführt wird für eine Entität, die im Unternehmen nicht mehr so existiert wie in den Kernunternehmensreferenzdaten im Bereich für verwaltete Daten dargestellt.
Verfahren nach Anspruch 58, wobei der Bereitstellungsbereich für ausgehende Daten aufweist: eine oder mehrere verbundene Bereitstellungstabellen für ausgehende Daten zur temporären Speicherung und Verarbeitung von ausgehenden Kernunternehmensreferenzdaten, die vor der Übertragung der ausgehenden Kernunternehmensreferenzdaten an ein oder mehrere Datenziele aus dem Bereich für verwaltete Daten extrahiert wurden; und eine oder mehrere unverbundene Bereitstellungstabellen für ausgehende Daten zur temporären Speicherung und Verarbeitung von ausgehenden Daten, die aus dem Bereitstellungsbereich für eingehende Daten entgegengenommen werden, aber nicht vor der Übertragung der ausgehenden Daten an ein oder mehrere Datenziele in den Bereich für verwaltete Daten geladen werden dürfen.
Verfahren nach Anspruch 50, das weiterhin warten einer relationalen Datenbank aufweist, die das zentralisierte Stammdepot enthält, wobei die relationale Datenbank ein Kernreferenzdatenmodell aufweist, das über ein zugeordnetes physisches Schema verfügt, wobei vorhandene objektorientierte interne Dienste auf das physische Schema unter Verwendung einer objektbezogene Zuweisungsebene zugewiesen sind.
Verfahren nach Anspruch 50, das weiterhin warten einer relationalen Datenbank aufweist, die das zentralisierte Stammdepot enthält, wobei die relationale Datenbank ein festes Kernreferenzdatenmodell aufweist, das über ein zugeordnetes festes physisches Schema verfügt, wobei eine niedrige Zugriffsebene beständige Objekte zur Verfügung stellt, die auf das feste physische Schema zugeschnitten sind, wobei neue objektorientierte interne Dienste unter Verwendung der spezifisch zugeschnittenen niedrigen Zugriffsebene dem festen physischen Schema zugewiesen werden.
Verfahren nach Anspruch 50, wobei das zentralisierte Stammdepot viele Stammdepots aufweist, die an vielen physischen Orten liegen, wobei das zentralisierte Stammdepot gegenüber internen Diensten und externen Betriebssystemen als ein einzelnes Stammdepot an einem einzelnen physischen Ort erscheint.
Verfahren nach Anspruch 50, das weiterhin warten einer Datenbank aufweist, die zumindest einige der Kernunternehmensreferenzdaten im zentralisierten Stammdepot enthält, wobei sämtliche Kernunternehmensreferenzdaten, die nicht physisch in der Datenbank enthalten sind, internen Diensten und externen Betriebssystemen so erscheint, als ob sie physisch in der Datenbank enthalten wären.
Verfahren nach Anspruch 50, wobei das zentralisierte Stammdepot ein multidimensionales Datenbankkonstrukt beinhaltet, in dem alle im zentralisierten Stammdepot gespeicherten Kernunternehmensreferenzdaten als ein Attribut dargestellt werden, das einem Punkt in einem n-dimensionalen Entitätenraum zugeordnet ist.
Verfahren nach Anspruch 66, wobei: die Kernunternehmensreferenzdaten Stammdaten aufweisen, die Kernkonfigurationsdaten repräsentieren, die Entitäten des Unternehmens zugeordnet sind; und ein Stamm einer Entität in der Lage ist der Entität zugeordnete Stammdaten auf dimensionale Weise zu erstellen, zu manipulieren, zu navigieren, zu sichten und zu extrahieren, um den einen oder die mehreren Geschäftsabläufe auf Unternehmensebene zu unterstützen.
Verfahren nach Anspruch 50, das weiterhin warten einer Datenbank aufweist: beinhaltend das zentralisierte Stammdepot; und ein konsistentes dimensionales Modellgefüge einschließt, das auf ein Modell angewendet wird, das einen Beständigkeits-Verwaltungsdienst unterstützt und es so erlaubt, dass die Kernunternehmensreferenzdaten konsistent mit bewährten dimensionalen Ansichten der Kernunternehmensreferenzdaten verwaltet werden können.
Verfahren nach Anspruch 50, wobei die Kernunternehmensreferenzdaten Stammdaten aufweisen.
Verfahren nach Anspruch 50, wobei das interne Dienstegefüge ein Geschäftsprozess-Toolkit zur Verwaltung von Modellen, die einem zentralisierten Stammdepot aufweisend das Stammdaten-Verwaltungssystem zugeordnet sind, aufweist, wobei das Geschäftsprozess-Toolkit aufweist: eine Modellbibliothek, die Datenmodelle enthält; und einen oder mehrere Modellierungsdienste zum Modellieren des Stammdatenverwaltungssystems, seiner Struktur und seiner Bestandteile.
Verfahren nach Anspruch 70, wobei die Modelle ein oder mehrere Prozessmodelle aufweisen, die Prozesse beschreiben, die für die Verwaltung der im zentralisierten Stammdepot gespeicherten Kernunternehmensreferenzdaten verwendet werden, wobei jedes Prozessmodell für einen entsprechenden Prozess eine Aufgabenabfolge beschreibt, die im Zusammenhang mit dem Prozess auf die Kernunternehmensreferenzdaten angewendet wird, wobei einer oder mehrere bestimmte interne Dienste mit diesen Aufgaben in Zusammenhang stehen, und eine oder mehrere bestimmte Prozess-Engines für die Ausführung des Prozesses verantwortlich sind.
Verfahren nach Anspruch 70, wobei die Modelle aufweisen: ein Dokumentenmodell, das Metadaten für Dokumente zur Verfügung stellt, die im Zusammenhang mit den Prozessen verwendet werden, die für die Verwaltung der im zentralisierten Stammdepot gespeicherten Kernunternehmensreferenzdaten zu verwenden sind, wobei jedes Dokument eine Darstellung von Metadatenelementen innerhalb eines zugrunde liegenden Kernunternehmensreferenzdatenmodells zur Verfügung stellt; ein Formenmodell, das Metadaten zur Verfügung stellt, die den Objekten im zugrunde liegenden Kernunternehmensreferenzdatenmodell zugeordnete Formen beschreiben; und ein Kernunternehmensreferenzdatenmodell, das Metadaten darstellt, die die im zentralisierten Stammdepot gespeicherten Kernunternehmensreferenzdaten beschreiben, wobei Änderungen an dem Kernunternehmensreferenzdatenmodell in der Lage sind, so in den Formen- und Dokumentenmodellen widergespiegelt zu werden, dass diese Modelle mit dem Kernunternehmensreferenzdatenmodell synchronisiert werden.
Verfahren nach Anspruch 72, wobei das interne Dienstegefüge in der Lage ist, die Formen- und Dokumentenmodelle als Reaktion auf Änderungen am Kernunternehmensreferenzdatenmodell automatisch mit dem Kernunternehmensreferenzdatenmodell zu synchronisieren.
Verfahren nach Anspruch 70, wobei die Modelle ein Kernunternehmensreferenzdatenmodell aufweisen, das Metadaten darstellt, die Kernunternehmensreferenzdaten beschreiben, die im zentralisierten Stammdepot gespeichert sind.
Verfahren nach Anspruch 74, wobei das Kernunternehmensreferenzdatenmodell ein Unternehmensmetamodell im Extensible Markup Language (XML) Software Description Format (XSD) aufweist, das die Metadaten von Instanzdaten trennt, um die Verwaltung von Metadaten zu ermöglichen, und das es einer Datenzugriffsebene in der Infrastrukturdiensteebene erlaubt, die Metadaten direkt aus der Modellbibliothek zu lesen.
Verfahren nach Anspruch 74, wobei das Kernunternehmensreferenzdatenmodell ein generisches Kernunternehmensreferenzdatenmodell aufweist, das eine Synthese von Datenelementen darstellt, die für eine Vielzahl von tatsächlichen Umsetzungen anwendbar sind, und das eine Obermenge von tatsächlichen Kernunternehmensreferenzdatenmodellen für die Verwendung in einer Vielzahl von tatsächlichen Umsetzungen aufweist, wobei jedes dieser tatsächlichen Kernunternehmensreferenzdatenmodelle vom generischen Kernunternehmensreferenzdatenmodell abgeleitet werden kann.
Verfahren nach Anspruch 70, wobei die Modelle aufweisen: ein Kernunternehmensreferenzdatenmodell, das Metadaten darstellt, die die im zentralisierten Stammdepot gespeicherten Kernunternehmensreferenzdaten beschreiben; und ein Bereitstellungsdatenmodell, das Metadaten darstellt, die Strukturen von Bereitstellungstabellen für ein- und ausgehende Daten einer Datenbank, die das zentralisierte Stammdepot zur Verfügung stellt, beschreiben, und das Zuweisungen zwischen dem Kernunternehmensreferenzdatenmodell und einer Darstellung von Daten in den Bereitstellungstabellen für ein- und ausgehende Daten in Bereitstellungstabellen zur Verfügung stellt, wobei zuweisen aufweist: für eingehende Daten eine Zuweisung des Kernunternehmensreferenzdatenmodells an ein Bereitstellungsdatenmodell für eingehende Daten, das ein beliebiges Eingangsdatenformat für ein externes Betriebssystem darstellt, wobei die Zuweisung ausgeführt wird, wenn eingehende Daten im zentralisierten Stammdepot als Kernunternehmensreferenzdaten gespeichert werden; und für ausgehende Daten eine Zuweisung des Kernunternehmensreferenzdatenmodells zu einem Bereitstellungsdatenmodell für ausgehende Daten, das eine flaches Ausgabedatenformat für ein externes Betriebssystem darstellt, wobei die Zuweisung ausgeführt wird, wenn Kernunternehmensreferenzdaten als ausgehende Daten aus dem zentralisierten Stammdepot verschoben werden.
Verfahren nach Anspruch 70, wobei die Modellierung eines oder mehrere aufweist aus: modellieren struktureler Aspekte einer Datenbank, die das zentralisierte Stammdepot zur Verfügung stellt; und modellieren von einem oder mehreren Geschäftsabläufen auf Unternehmensebene.
Verfahren nach Anspruch 70, wobei ein oder mehrere Modellierungsdienste einen Strukturaktualisierungsdienst aufweisen, der einen Mechanismus zur Verfügung stellt, mit dem ein Strukturmodell erzeugt oder modifiziert und in Reaktion darauf das erzeugte oder modifizierte Strukturmodell automatisch in eine tatsächliche Umsetzung integriert werden kann.
Verfahren nach Anspruch 50, wobei das interne Dienstegefüge einen oder mehrere Dienste aufweist aus: Datensicherheitsdienste, die Authentifizierungs- und Autorisierungsdienste aufweisen; allgemeine Datendienste, die Änderungsverwaltung, Lebenszyklusverwaltung, Gruppenverwaltung und Analyse- und Berichtsdienste aufweisen; Datenzugriffsdienste, die beständige Verwaltung und Datenzugriffsebenendienste aufweisen; und Datenbereitstellungsdienste, die Datenimport-, Überprüfungs- und Syndizierungsdienste aufweisen.
Verfahren nach Anspruch 50, wobei die Infrastrukturdiensteebene eine Back-Side Datenzugriffsebene aufweist, die in der Lage ist um: externen Betriebssystemen indirekten Zugriff auf zugeordnete externe Betriebsdienste bereitzustellen, die indirekt über einen oder mehrere dem zentralisierten Kerndepot zugeordnete Bereitstellungsbereiche auf die Kernunternehmensreferenzdaten innerhalb des zentralisierten Kerndepots zugreifen; Massendatentransfers von Kernunternehmensreferenzdaten zwischen dem zentralisierten Stammdepot und den externen Betriebssystemen bereitzustellen; und Datenintegration in die externen Betriebssysteme zu ermöglichen.
Verfahren nach Anspruch 50, wobei die Infrastrukturdiensteebene auch Mitteilungsübermittlung innerhalb eines Unternehmens zwischen einem oder mehreren der internen Diensten und den externen Betriebssystemen entsprechend der Vorgehensweise eines oder mehrerer Geschäftsabläufe auf Unternehmensebene zur Verfügung stellt.
Verfahren nach Anspruch 50, wobei die Infrastrukturdiensteebene eine Front-Side Datenzugriffsebene aufweist, die in der Lage ist um: den externen Betriebssystemen direkten Zugriff auf bestimmte der interne Dienste bereitzustellen, die direkt auf die Kernunternehmensreferenzdaten im zentralisierten Kerndepot zugreifen; Kontrolldaten von den externen Betriebssystemen zu übertragen, um interne Vorgänge zu kontrollieren; und Integration von Anwendungen in die externen Betriebssysteme zu ermöglichen.
Verfahren nach Anspruch 83, wobei die Front-Side Datenzugriffsebene unter Verwendung einer objektbasierten Diensteebene verkörpert ist, die auf einem Anwendungsserver in einer Anwendungsserverebene liegt.
Verfahren nach Anspruch 50, wobei die Infrastrukturdiensteebene aufweist: eine Back-Side Datenzugriffsebene, die in der Lage ist, Massendatentransfers von Kernunternehmensreferenzdaten zwischen dem zentralisierten Stammdepot und den externen Betriebssystemen zur Verfügung zu stellen; und eine Front-Side Datenzugriffsebene, die in der Lage ist um: Kontrolldaten von den externen Betriebssystemen zu übertragen, um die internen Vorgänge zu kontrollieren; und Kernunternehmensreferenzdaten zwischen dem zentralisierten Stammdepot und einem externen Betriebssystem zu übertragen, wobei das externe Betriebssystem Kernunternehmensreferenzdaten in einem bestimmten Format benötigt, das die Back-Side Datenzugriffsebene nicht unterstützt.
Verfahren nach Anspruch 50, weiterhin aufweist bereitstellen: einer logischen Prozessebene, die einen Kontext für die Einführung und vollständige oder partielle Automatisierung von Geschäftskonfigurationsprozessen zur Verfügung stellt, die dem einem oder den mehreren Geschäftsabläufen auf Unternehmensebene zugeordnet sind; einer logischen Dienstebene, die der logischen Prozessebene zugrunde liegt und Dienstfunktionen zur Verfügung stellt, die Prozessaufgaben für die automatisierten Geschäftskonfigurationsprozesse ermöglichen; und eine logische Datenebene, die der logischen Dienstebene zugrunde liegt und grundlegende Datenmodelle und physische Darstellungen zum Speichern der Kernunternehmensreferenzdaten zur Gewinnung und Verwendung im Zusammenhang mit den Geschäftskonfigurationsprozessen und Dienstfunktionen zur Verfügung stellt.
Verfahren nach Anspruch 50, das weiterhin einen oder mehrere der Geschäftsabläufe aufweist, wobei die eingebetteten Geschäftsabläufe auf Unternehmensebene unter Verwendung einer Arbeitsablauf-Engine auf Unternehmensebene zur vollständigen oder partiellen Automatisierung eines oder mehrerer zugeordneter Geschäftsprozesse auf Unternehmensebene vollständig oder partiell automatisiert sind.
Verfahren nach Anspruch 87, wobei ein automatisierter Geschäftsprozess auf Unternehmensebene den Einführungsprozess für eine neue Entität aufweist.
Verfahren nach Anspruch 88, wobei der automatisierte Einführungsprozess für eine neue Entität ein automatisierter Einführungsprozess für einen neuen Artikel in einem Einzelhandelsunternehmen ist, wobei der automatisierte Einführungsprozess für einen neuen Artikel aufweist hinzufügen von neuen Kernunternehmensreferenzdaten für den neuen Artikel zum zentralisierten Stammdepot, überprüfen der neuen Kernunternehmensreferenzdaten für den neuen Artikel, der Verwendung des neuen Artikels zustimmen und den neuen Artikel als verfügbar zur Verwendung durch die externen Betriebssysteme zu veröffentlichen.
Verfahren nach Anspruch 89, wobei der neue Artikel als verfügbar für die Verwendung durch die externen Betriebssysteme durch Nachbildung für die interne Verwendung durch die externe Betriebssysteme und nicht für direkten Zugriff auf den neuen Artikel innerhalb des zentralisierten Stammdepots durch die externen Betriebssysteme veröffentlicht wird.
Verfahren nach Anspruch 89, wobei der automatisierte Einführungsprozess für den neuen Artikel aufweist: erzeugen und speichern eines oder mehrerer Stämme für den neuen Artikel innerhalb des zentralisierten Stammdepots; und die externen Betriebssysteme erhalten und erkennen den neuen Artikel für Merchandising, Lagerauffüllung und Lieferkettenplanungs- und – ausführungsvorgänge.
Verfahren nach Anspruch 91, wobei der eine oder die mehreren Stämme für den neuen Artikel einen Artikelstamm, einen Artikelortstamm und einen Verkäuferartikelstamm aufweisen.
Verfahren nach Anspruch 89, wobei der automatisierte Einführungsprozess für einen neuen Artikel rationalisierte Integration in externe Betriebssysteme zur Verfügung stellt, die Merchandising, Lagerauffüllung und Lieferkettenplanungs- und – ausführungsvorgänge im Hinblick auf den neuen Artikel zur Verfügung stellen.
Verfahren nach Anspruch 93, wobei die rationalisierte Integration eines oder mehrere aufweist aus: Daten aus einem Verkäuferangebot, das dem neuen Artikel zugeordnet ist, werden automatisch eingetragen und müssen nicht manuell eingegeben werden, um einen Vertrag über den neuen Artikel abzuschließen; eine universelle Produktnummer (UPC) wird automatisch für den neuen Artikel erzeugt, sobald der neue Artikel erzeugt wurde, und muss nicht mehr manuell eingegeben werden; ein bereits vorhandenes System des Einzelhändlers wird automatisch überprüft, so dass sichergestellt werden kann, dass die UPC Nummer für den neuen Artikel einer Einzelhändlerproduktnummer zugeordnet ist, und muss nicht mehr manuell überprüft werden; und eine Einzelhändlerproduktnummer für ein neues Produkt wird automatisch für die Erzeugung eines Produktsortiments eingetragen, das den neuen Artikel einschließt, und muss nicht mehr manuell eingegeben werden.
Verfahren nach Anspruch 50, wobei: ein Unternehmenslösungsgefüge für das Unternehmen aufweist: ein Konfigurationssegment, das eine Konfiguration des Unternehmens spezifiziert; ein Planungssegment zur Planung hinsichtlich des Unternehmens und seiner Entitäten entsprechend der im Konfigurationssegment spezifizierten Konfiguration des Unternehmens, wobei Planung die Entscheidungerzeugung aufweist, die Aktionen spezifiziert, die durchzuführen sind; ein Ausführungssegment zur Ausführung hinsichtlich des Unternehmens und seiner Entitäten entsprechend dem Ergebnis des Planungssegmentes, wobei die Ausführung das Durchführen von Aktionen aufweist, die auf den im Planungssegment erzeugten Entscheidungen basieren; und ein Überwachungssegment zur Überwachung hinsichtlich des Unternehmens und seiner Entitäten entsprechend dem Ergebnis des Ausführungssegments, wobei die Überwachung bestimmen von Ergebnissen von Aktionen, die im Ausführungssegment durchgeführt wurden, sowie das Bereitstellen von Feedback bezüglich der Konfigurations- und Planungssegmente aufweist; das zentralisierte Stammdepot und zugeordneten Dienste das Konfigurationssegment verkörpern; und eine Vielzahl externer Betriebssysteme die Planungs-, Ausführungs- und Überwachungssegmente verkörpern.
Verfahren nach Anspruch 50, wobei jedes von einem oder mehreren externen Betriebssystemen aufweist: ein Planungssystem; ein Ausführungssystem; oder ein Überwachungssystem.
Verfahren nach Anspruch 96, wobei das Unternehmen ein Einzelhandelsunternehmen ist und die externen Betriebssysteme aufweisen: ein Merchandising-Planungssystem; ein Ergänzungsplanungssystem; ein Auftragsverwaltungssystem; und ein Logistik- und Vertriebssystem.
Verfahren nach Anspruch 50, wobei die externen Betriebssysteme eines oder mehrere aufweisen aus: externe Unternehmenslösungskomponenten, die dem Unternehmen zugeordnet sind; und externe Unternehmen.
Software zur zentrale Verwaltung von Kernunternehmensreferenzdaten, die einem Unternehmen zugeordnet sind, wobei die Software in computerlesbaren Medien verkörpert und bei der Ausführung in der Lage ist, ein System zur Verfügung zu stellen, das aufweist: ein zentralisiertes Stammdepot, das die Kernunternehmensreferenzdaten enthält; ein internes Dienstegefüge, das mit dem zentralisierten Stammdepot verbunden ist und interne Dienste für die Verwaltung der Kernunternehmensreferenzdaten im zentralisierten Stammdepot zur Verfügung stellt, wobei einer oder mehrere der internen Dienste direkten Zugriff auf die Kernunternehmensreferenzdaten besitzt, die für Verwaltungszwecke im zentralisierten Stammdepot gespeichert werden; und eine Infrastrukturdienstebene, die mit dem zentralisierten Stammdepot verbunden ist und Massendatentransfers von Kernunternehmensreferenzdaten zwischen dem zentralisierten Stammdepot und einem oder mehreren externen Betriebssystemen gemäß eines oder mehrerer Arbeitsabläufe auf Unternehmensebene zur Verfügung stellt, wobei den externen Betriebssysteme indirekter Zugriff auf die Kernunternehmensreferenzdaten gestattet ist, die für Betriebszwecke im zentralisierten Stammdepot gespeichert sind.
Software nach Anspruch 99, die in der Lage ist, ein sicheres Aufzeichnungssystem zur Verfügung zu stellen, das in Design und Architektur für die Verwaltung von Kernunternehmensreferenzdaten und nicht für die betriebliche Verwendung der Kernunternehmensreferenzdaten durch die externen Betriebssystemen optimiert ist.
Software nach Anspruch 99, wobei ein externer Zugriffsdienst einen Mechanismus zur Verfügung stellt, der es erlaubt, die Kernunternehmensreferenzdaten im zentralisierten Stammdepot in beständigen Speichern der externen Betriebssysteme für die betriebliche Verwendung durch die externen Betriebssysteme nachzubilden, wobei den externen Betriebssysteme kein direkter Zugriff auf die Kernunternehmensreferenzdaten im zentralisierten Stammdepot gestattet ist.
Software nach Anspruch 99, wobei bereitstellen zentralisierter Speicherung und Verwaltung der Kernunternehmensreferenzdaten im zentralisierten Stammdepot die Anpassung eines externen Betriebssystems ermöglicht, ohne dass dafür die Kernunternehmensreferenzdaten im zentralisierten Stammdepot angepasst werden müssen.
Software nach Anspruch 99, wobei bereitstellen zentralisierter Speicherung und Verwaltung von Kernunternehmensreferenzdaten im zentralisierten Stammdepot die Integration eines externen Betriebssystems ermöglicht, wenn das externe Betriebssystem eingeführt, modifiziert oder ersetzt wird.
Software nach Anspruch 99, wobei bereitstellen zentralisierter Speicherung und Verwaltung von Kernunternehmensreferenzdaten im zentralisierten Stammdepot die Integration eines anderen Unternehmens in das Unternehmen ermöglicht.
Software nach Anspruch 99, die in der Lage ist, eine Datenbank zur Verfügung zu stellen, die aufweist: einen Bereich für verwaltete Daten, der das zentralisierte Stammdepot zur Verfügung stellt, das die Kernunternehmensreferenzdaten enthält; einen Bereich für zwischengespeicherte Daten, der einem oder mehreren interne Dienste direkten Zugriff auf die Kernunternehmensreferenzdaten zur Verfügung stellt, wobei der Bereich für zwischengespeicherte Daten zwischengespeicherte Daten enthält, die Kernunternehmensreferenzdaten repräsentieren, die zur Verarbeitung im Zusammenhang mit dem einem oder den mehreren internen Diensten aus dem Bereich für verwaltete Daten extrahiert und nach solcher Verarbeitung wieder in den Bereich für verwaltete Daten eingefügt wurden; und einen Betriebszugriffsbereich, der den externen Betriebssystemen indirekten Zugriff auf die Kernunternehmensreferenzdaten zur Verfügung stellt, wobei der Betriebszugriffsbereich einen Bereitstellungsbereich für Kernunternehmensreferenzdaten enthält, die zwischen dem Bereich für verwaltete Daten und den externen Betriebssystemen zugeordneten beständigen Datenspeichern übertragen werden.
Software nach Anspruch 105, wobei: der Bereich für zwischengespeicherte Daten einen Mechanismus zur Verfügung stellt, der eine Kopie von Kernunternehmensreferenzdaten als zwischengespeicherte Daten in einem vorübergehenden Status zur Manipulation gemäß eines Manipulationsvorgang zurückhält; und die Kernunternehmensreferenzdaten im Bereich für verwaltete Daten im tatsächlichen Status zum Nur-Lesezugriff gesperrt bleiben, bis der Manipulationsvorgang abgeschlossen ist, wobei der Manipulationsvorgang über den vorübergehenden Status der zwischengespeicherten Daten im Bereich für zwischengespeicherte Daten informiert ist und den noch nicht abgeschlossenen Manipulationsvorgang und nicht den tatsächlichen Status der Kernunternehmensreferenzdaten im Bereich für verwaltete Daten widerspiegelt, wobei andere Prozesse, die dem zur Verfügung gestellten System zugeordnet sind, über den tatsächlichen Status der Kernunternehmensreferenzdaten im Bereich für verwaltete Daten und nicht den vorübergehenden Status der zwischengespeicherten Daten im Bereich für zwischengespeicherte Daten informiert sind, der den noch nicht abgeschlossenen Manipulationsvorgang widerspiegelt.
Software nach Anspruch 99, die in der Lage ist, eine Datenbank zur Verfügung zu stellen, die aufweist: einen Bereich für verwaltete Daten, der das zentralisierte Stammdepot zur Verfügung stellt, das die Kernunternehmensreferenzdaten enthält; einen Bereitstellungsbereich für eingehende Daten für temporäre Speicherung und Verarbeitung von eingehenden Kernunternehmensreferenzdaten erhaltenen aus einer oder mehreren Datenquellen vor dem Laden der eingehenden Kernunternehmensreferenzdaten in den Bereich für verwaltete Daten; und einen Bereitstellungsbereich für ausgehende Daten für temporäre Speicherung und Verarbeitung von ausgehenden Kernunternehmensreferenzdaten, die vor der Übertragung der ausgehenden Kernunternehmensreferenzdaten an ein oder mehrere Datenziele aus dem Bereich für verwaltete Daten extrahiert wurden.
Software nach Anspruch 107, wobei die Kernunternehmensreferenzdaten im Bereich für verwaltete Daten im Wesentlichen kontinuierlich mit den ausgehenden Kernunternehmensreferenzdaten im Bereitstellungsbereich für ausgehende Daten synchronisiert werden, so dass im Bereitstellungsbereich für ausgehende Daten zu jedem Zeitpunkt eine genaue Übersicht über die Kernunternehmensreferenzdaten im Bereich für verwaltete Daten zur Verfügung steht.
Software nach Anspruch 108, wobei: ausgehende Kernunternehmensreferenzdaten Betriebsdaten aufweisen, die für externe Betriebssysteme bestimmt sind; und die Synchronisierung der Betriebsdaten im Bereitstellungsbereich für ausgehende Daten mit den Kernunternehmensreferenzdaten im Bereich für verwaltete Daten dabei hilft, sicherzustellen, dass Planung basierend auf den Betriebsdaten nicht ausgeführt wird für eine Entität, die im Unternehmen nicht mehr so existiert wie in den Kernunternehmensreferenzdaten im Bereich für verwaltete Daten dargestellt.
Software nach Anspruch 107, wobei der Bereich für ausgehende Daten aufweist: eine oder mehrere verbundene Bereitstellungstabellen für ausgehende Daten zur temporären Speicherung und Verarbeitung von ausgehenden Kernunternehmensreferenzdaten, die vor der Übertragung der ausgehenden Kernunternehmensreferenzdaten an ein oder mehrere Datenziele aus dem Bereich für verwaltete Daten extrahiert wurden; und eine oder mehrere unverbundene Bereitstellungstabellen für ausgehende Daten zur temporären Speicherung und Verarbeitung von ausgehenden Daten, die aus dem Bereitstellungsbereich für eingehende Daten entgegengenommen werden, aber nicht vor der Übertragung der ausgehenden Daten an ein oder mehrere Datenziele in den Bereich für verwaltete Daten geladen werden dürfen.
Software nach Anspruch 99, die in der Lage ist, eine relationale Datenbank zur Verfügung zu stellen, die das zentralisierte Stammdepot enthält, wobei die relationale Datenbank ein Kernreferenzdatenmodell aufweist, das über ein zugeordnetes physisches Schema verfügt, wobei vorhandene objektorientierte interne Dienste unter Verwendung einer objektbezogenen Zuweisungsebene dem physischen Schema zugewiesen sind.
Software nach Anspruch 99, die in der Lage ist, eine relationale Datenbank zur Verfügung zu stellen, die das zentralisierte Stammdepot enthält, wobei die relationale Datenbank ein festes Kernreferenzdatenmodell aufweist, das über ein zugeordnetes festes physisches Schema verfügt, wobei eine niedrige Zugriffsebene beständige Objekte zur Verfügung stellt, die auf das feste physische Schema zugeschnitten sind, wobei neue objektorientierte interne Dienste unter Verwendung der spezifisch zugeschnittenen niedrigen Zugriffsebene dem festen physischen Schema zugewiesen werden.
Software nach Anspruch 99, wobei das zentralisierte Stammdepot viele Stammdepots aufweist, die an vielen physischen Orten liegen, wobei das zentralisierte Stammdepot gegenüber internen Diensten und externen Betriebssystemen als ein einzelnes Stammdepot an einem einzelnen physischen Ort erscheint.
Software nach Anspruch 99, die in der Lage ist, eine Datenbank zur Verfügung zu stellen, die zumindest einige der Kernunternehmensreferenzdaten im zentralisierten Stammdepot enthält, wobei sämtliche Kernunternehmensreferenzdaten, die nicht physisch in der Datenbank enthalten sind, gegenüber internen Diensten und externen Betriebssystemen so erscheinen, als ob sie physisch in der Datenbank enthalten wären.
Software nach Anspruch 99, wobei das zentralisierte Stammdepot ein multidimensionales Datenbankkonstrukt einschließt, in dem alle im zentralisierten Stammdepot gespeicherten Kernunternehmensreferenzdaten als ein Attribut dargestellt werden, das einem Punkt in einem n-dimensionalen Entitätenraum zugeordnet ist.
Software nach Anspruch 115, wobei: die Kernunternehmensreferenzdaten Stammdaten aufweisen, die Kernkonfigurationsdaten repräsentieren, die Entitäten des Unternehmens zugeordnet sind; und ein Stamm einer Entität in der Lage ist Stammdaten, die der Entität zugeordnet sind, auf dimensionale Weise zu erstellen, zu manipulieren, zu navigieren, zu sichten und zu extrahieren, um den einen oder die mehreren Geschäftsabläufe auf Unternehmensebene zu unterstützen.
Software nach Anspruch 99, die in der Lage ist, eine Datenbank zur Verfügung zu stellen: enthaltend das zentralisierte Stammdepot; und ein konsistentes dimensionales Modellgefüge einschließt, das auf ein Modell angewendet wird, das einen Beständigkeits-Verwaltungsdienst unterstützt und es so erlaubt, dass die Kernunternehmensreferenzdaten konsistent mit bewährten dimensionalen Ansichten der Kernunternehmensreferenzdaten verwaltet werden können.
Software nach Anspruch 99, wobei die Kernunternehmensreferenzdaten Stammdaten aufweisen und das zur Verfügung gestellte System ein Stammdaten-Verwaltungssystem aufweist.
Software nach Anspruch 99, wobei das interne Dienstegefüge ein Geschäftsprozess-Toolkit zur Verwaltung von Modellen aufweist, die dem zur Verfügung gestellten System zugegordnet sind, wobei das Geschäftsprozess-Toolkit aufweist: eine Modellbibliothek, die Datenmodelle enthält; und einen oder mehrere Modellierungsdienste zum Modellieren des zur Verfügung gestellten Systems, seiner Struktur und seiner Bestandteile.
Software nach Anspruch 119, wobei die Modelle ein oder mehrere Prozessmodelle aufweisen, die Prozesse beschreiben, die für die Verwaltung der im zentralisierten Stammdepot gespeicherten Kernunternehmensreferenzdaten verwendet werden, wobei jedes Prozessmodell für einen entsprechenden Prozess eine Aufgabenabfolge beschreibt, die im Zusammenhang mit dem Prozess auf die Kernunternehmensreferenzdaten angewendet wird, wobei einer oder mehrere bestimmte interne Dienste mit diesen Aufgaben in Zusammenhang stehen, und einer oder mehrere bestimmte Prozess-Engines für die Ausführung des Prozesses verantwortlich sind.
Software nach Anspruch 119, wobei die Modelle aufweisen: ein Dokumentenmodell, das Metadaten für Dokumente bereitstellt, die im Zusammenhang mit den Prozessen verwendet werden, die für die Verwaltung der im zentralisierten Stammdepot gespeicherten Kernunternehmensreferenzdaten verwendet werden, wobei jedes Dokument eine Darstellung von Metadatenelementen innerhalb eines zugrunde liegenden Kernunternehmensreferenzdatenmodells zur Verfügung stellt; ein Formenmodell, das Metadaten zur Verfügung stellt, die Formen beschreiben, die Objekten im zugrunde liegenden Kernunternehmensreferenzdatenmodell zugeordnet sind; und ein Kernunternehmensreferenzdatenmodell, das Metadaten darstellt, die die im zentralisierten Stammdepot gespeicherten Kernunternehmensreferenzdaten beschreiben, wobei Änderungen an dem Kernunternehmensreferenzdatenmodell in der Lage sind, so in den Formen- und Dokumentenmodellen widergespiegelt zu werden, dass diese Modelle mit dem Kernunternehmensreferenzdatenmodell synchronisiert werden.
Software nach Anspruch 121, wobei das interne Dienstegefüge in der Lage ist, die Formen- und Dokumentenmodelle als Reaktion auf Änderungen am Kernunternehmensreferenzdatenmodell automatisch mit dem Kernunternehmensreferenzdatenmodell zu synchronisieren.
Software nach Anspruch 119, wobei die Modelle ein Kernunternehmensreferenzdatenmodell aufweisen, das Metadaten repräsentiert, die Kernunternehmensreferenzdaten beschreiben, die im zentralisierten Stammdepot gespeichert sind.
Software nach Anspruch 123, wobei das Kernunternehmensreferenzdatenmodell ein Unternehmensmetamodell im Format Extensible Markup Language (XML) Software Description Format (XSD) aufweist, das die Metadaten von Instanzdaten trennt, um die Verwaltung von Metadaten zu ermöglichen, und das es einer Datenzugriffsebene in der Infrastrukturdiensteebene erlaubt, die Metadaten direkt aus der Modellbibliothek zu lesen.
Software nach Anspruch 123, wobei das Kernunternehmensreferenzdatenmodell ein generisches Kernunternehmensreferenzdatenmodell aufweist, das eine Synthese von Datenelementen darstellt, die für eine Vielzahl von tatsächlichen Umsetzungen des zur Verfügung gestellten Systems anwendbar sind, und das eine Obermenge von tatsächlichen Kernunternehmensreferenzdatenmodellen für die Verwendung in einer Vielzahl von tatsächlichen Umsetzungen des zur Verfügung gestellten Systems aufweist, wobei jedes dieser tatsächlichen Kernunternehmensreferenzdatenmodelle vom generischen Kernunternehmensreferenzdatenmodell abgeleitet werden kann.
Software nach Anspruch 119, wobei die Modelle aufweisen: ein Kernunternehmensreferenzdatenmodell, das Metadaten darstellt, die die im zentralisierten Stammdepot gespeicherten Kernunternehmensreferenzdaten beschreiben; und ein Bereitstellungsdatenmodell, das Metadaten darstellt, die Strukturen von Bereitstellungstabellen für ein- und ausgehende Daten einer Datenbank, die das zentralisierte Stammdepot zur Verfügung stellt, beschreiben, und das Zuweisungen zwischen dem Kernunternehmensreferenzdatenmodell und einer Darstellung von Daten in den Bereitstellungstabellen für ein- und ausgehende Daten in Bereitstellungstabellen zur Verfügung stellt, wobei die Zuweisungen aufweisen: für eingehende Daten eine Zuweisung des Kernunternehmensreferenzdatenmodells zu einem Bereitstellungsdatenmodell für eingehende Daten, das ein beliebiges Eingangsdatenformat für ein externes Betriebssystem darstellt, wobei die Zuweisung ausgeführt wird, wenn eingehende Daten im zentralisierten Stammdepot als Kernunternehmensreferenzdaten gespeichert werden; und für ausgehende Daten eine Zuweisung des Kernunternehmensreferenzdatenmodells zu einem Bereitstellungsdatenmodell für ausgehende Daten, das eine flaches Ausgabedatenformat für ein externes Betriebssystem darstellt, wobei die Zuweisung ausgeführt wird, wenn Kernunternehmensreferenzdaten als ausgehende Daten aus dem zentralisierten Stammdepot verschoben werden.
Software nach Anspruch 119, wobei die Modellierung eines oder aufweist aus: Modellieren struktureler Aspekte einer Datenbank, die das zentralisierte Stammdepot zur Verfügung stellt; und Modellieren von einem oder mehreren Geschäftsabläufen auf Unternehmensebene.
Software nach Anspruch 119, wobei der ein oder die mehreren Modellierungsdienste einen Strukturaktualisierungsdienst aufweisen, der einen Mechanismus zur Verfügung stellt, mit dem ein Strukturmodell erzeugt oder modifiziert und in Reaktion darauf das erzeugte oder modifizierte Strukturmodell automatisch in eine tatsächliche Umsetzung des zur Verfügung gestellten Systems integriert werden kann.
Software nach Anspruch 99, wobei das interne Dienstegefüge einen oder mehrere Dienste aufweist aus: Datensicherheitsdienste, die Authentifizierungs- und Autorisierungsdienste aufweisen; allgemeine Datendienste, die Änderungsverwaltung, Lebenszyklusverwaltung, Gruppenverwaltung und Analyse- und Berichtsdienste aufweisen; Datenzugriffsdienste, die beständige Verwaltung und Datenzugriffsebenendienste aufweisen; und Datenbereitstellungsdienste, die Datenimport-, Überprüfungs- und Syndizierungsdienste aufweisen.
Software nach Anspruch 99, wobei die Infrastrukturdiensteebene eine Back-Side Datenzugriffsebene aufweist, die in der Lage ist um: externen Betriebssystemen indirekten Zugriff auf zugeordnete externe Betriebsdienste innerhalb des zur Verfügung gestellten Systems bereitzustellen, die indirekt über einen oder mehrere dem zentralisierten Kerndepot zugewiesene Bereitstellungsbereiche auf die Kernunternehmensreferenzdaten innerhalb des zentralisierten Kerndepots zugreifen; Massendatentransfers von Kernunternehmensreferenzdaten zwischen dem zentralisierten Stammdepot und den externen Betriebssystemen bereitzustellen; und Datenintegration in die externen Betriebssysteme zu ermöglichen.
Software nach Anspruch 99, wobei die Infrastrukturdiensteebene auch die Mitteilungsübermittlung innerhalb eines Unternehmens zwischen einem oder mehreren der internen Diensten und den externen Betriebssystemen entsprechend der Vorgehensweise eines oder mehrerer Geschäftsabläufe auf Unternehmensebene zur Verfügung stellt.
Software nach Anspruch 99, wobei die Infrastrukturdiensteebene eine Front-Side Datenzugriffsebene aufweist, die in der Lage ist um: den externen Betriebssysteme direkten Zugriff auf bestimmte der internen Dienste zur Verfügung zu stellen, die direkt auf die Kernunternehmensreferenzdaten im zentralisierten Kerndepot zugreifen; Kontrolldaten von den externen Betriebssystemen auf das zur Verfügung gestellte System zur Verfügung zu stellen, um Vorgänge des zur Verfügung gestellten Systems zu kontrollieren; und Integration von Anwendungen in die externen Betriebssysteme zu ermöglichen.
Software nach Anspruch 132, wobei die Front-Side Datenzugriffsebene unter Verwendung einer objektbasierten Diensteebene verkörpert ist, die auf dem Anwendungsserver in einer Anwendungsserverebene liegt.
Software nach Anspruch 99, wobei die Infrastrukturdiensteebene aufweist: eine Back-Side Datenzugriffsebene, die in der Lage ist, Massendatentransfers von Kernunternehmensreferenzdaten zwischen dem zentralisierten Stammdepot und den externen Betriebssystemen zur Verfügung zu stellen; und eine Front-Side Datenzugriffsebene, die in der Lage ist um: Kontrolldaten von den externen Betriebssystemen auf das zur Verfügung gestellte System zu übertragen, um Vorgänge des zur Verfügung gestellten Systems zu kontrollieren; und Kernunternehmensreferenzdaten zwischen dem zentralisierten Stammdepot und den externen Betriebssystemen zu übertragen, wobei die externen Betriebssysteme Kernunternehmensreferenzdaten in einem bestimmten Format benötigen, das die Back-Side Datenzugriffsebene nicht unterstützt.
Software nach Anspruch 99, die in der Lage ist, zur Verfügung zu stellen: eine logische Prozessebene, die einen Kontext für die Einführung und vollständige oder partielle Automatisierung von Geschäftskonfigurationsprozessen zur Verfügung stellt, die dem einem oder den mehreren Geschäftsabläufen auf Unternehmensebene zugeordnet sind; eine logische Dienstebene, die der logischen Prozessebene zugrunde liegt und Dienstfunktionen zur Verfügung stellt, die Prozessaufgaben für die automatisierten Geschäftskonfigurationsprozesse ermöglichen; und eine logische Datenebene, die der logischen Dienstebene zugrunde liegt und grundlegende Datenmodelle und physische Darstellungen zum Speichern der Kernunternehmensreferenzdaten zur Gewinnung und Verwendung im Zusammenhang mit den Geschäftskonfigurationsprozessen und Dienstfunktionen zur Verfügung stellt.
Software nach Anspruch 99, wobei einer oder mehrere der Geschäftsabläufe auf Unternehmensebene eingebettet sind und unter Verwendung einer Arbeitsablauf-Engine auf Unternehmensebene zur vollständigen oder partiellen Automatisierung eines oder mehrerer zugeordneter Geschäftsprozesse auf Unternehmensebene vollständig oder partiell automatisiert sind.
Software nach Anspruch 136, wobei ein automatisierter Geschäftsprozess auf Unternehmensebene einen Einführungsprozess für eine neue Entität aufweist.
Software nach Anspruch 137, wobei der automatisierte Einführungsprozess für eine neue Entität ein automatisierter Einführungsprozess für einen neuen Artikel in einem Einzelhandelsunternehmen ist, wobei der automatisierte Einführungsprozess für einen neuen Artikel aufweist hinzufügen von neuen Kernunternehmensreferenzdaten für den neuen Artikel zum zentralisierten Stammdepot, überprüfen der neuen Kernunternehmensreferenzdaten für den neuen Artikel, der Verwendung des neuen Artikels zustimmen und den neuen Artikels als verfügbar zur Verwendung durch die externen Betriebssysteme zu veröffentlichen.
Software nach Anspruch 138, wobei der neue Artikel als verfügbar für die Verwendung durch die externen Betriebssysteme durch Nachbildung für interne Verwendung durch die externe Betriebssysteme und nicht für direkten Zugriff auf den neuen Artikel innerhalb des zentralisierten Stammdepots durch die externen Betriebssysteme veröffentlicht wird.
Software nach Anspruch 138, wobei der automatisierte Einführungsprozess für einen neuen Artikel aufweist: erzeugen und speichern eines oder mehrerer Stämme für den neuen Artikel innerhalb des zentralisierten Stammdepots; und die externen Betriebssysteme erhalten und erkennen den neuen Artikel für Merchandising, Lagerauffüllung und Lieferkettenplanungs- und – ausführungsvorgänge.
Software nach Anspruch 140, wobei der eine oder die mehreren Stämme für den neuen Artikel einen Artikelstamm, einen Artikelortstamm und einen Verkäuferartikelstamm aufweisen.
Software nach Anspruch 138, wobei der automatisierte Einführungsprozess für einen neuen Artikel rationalisierte Integration in externe Betriebssysteme zur Verfügung stellt, die Merchandising, Lagerauffüllung und Lieferkettenplanungs- und -ausführungsvorgänge für den neuen Artikel zur Verfügung stellen.
Software nach Anspruch 142, wobei die rationalisierte Integration eines oder mehrere aufweist aus: Daten aus einem Verkäuferangebot, das dem neuen Artikel automatisch zugeordnet ist, werden automatisch eingetragen und müssen nicht manuell eingegeben werden, um einen Vertrag im Hinblick auf den neuen Artikel abzuschließen; eine universelle Produktnummer (UPC) wird automatisch für den neuen Artikel erzeugt, sobald der neue Artikel erzeugt ist, und muss nicht mehr manuell eingegeben werden; ein bereits vorhandenes System des Einzelhändlers wird automatisch überprüft, so dass sichergestellt werden kann, dass die UPC Nummer des neuen Artikels einer Einzelhändlerproduktnummer zugeordnet ist, und muss nicht mehr manuell überprüft werden; und eine Einzelhändlerproduktnummer für ein neues Produkt wird automatisch für die Erzeugung eines Produktsortiments eingetragen, das den neuen Artikel einschließt, und muss nicht mehr manuell eingegeben werden.
Software nach Anspruch 99, wobei: ein Unternehmenslösungsgefüge für das Unternehmen aufweist: ein Konfigurationssegment, das eine Konfiguration des Unternehmens spezifiziert; ein Planungssegment zur Planung hinsichtlich des Unternehmens und seiner Entitäten entsprechend der im Konfigurationssegment spezifizierten Konfiguration des Unternehmens, wobei Planung die Entscheidungserzeugung aufweist, die Aktionen spezifiziert, die durchzuführen zu sind; ein Ausführungssegment zur Ausführung hinsichtlich des Unternehmens und seiner Entitäten entsprechend dem Ergebnis des Planungssegmentes, wobei die Ausführung das Durchführen von Aktionen aufweist, die auf den im Planungssegment getroffenen Entscheidungen basieren; und ein Überwachungssegment zur Überwachung hinsichtlich des Unternehmens und seiner Entitäten entsprechend dem Ergebnis des Ausführungssegments, wobei die Überwachung bestimmen von Ergebnissen von Aktionen, die im Ausführungssegment durchgeführt wurden, sowie bereitstellen von Feedback bezüglich der Konfigurations- und Planungssegmente aufweist; das zur Verfügung gestellte System das Konfigurationssegment verkörpert; und eine Vielzahl externer Betriebssysteme die Planungs-, Ausführungs- und Überwachungssegmente verkörpern.
Software nach Anspruch 99, wobei jedes von einem oder mehreren externen Betriebssystemen aufweist: ein Planungssystem; ein Ausführungssystem; oder ein Überwachungssystem.
Software nach Anspruch 145, wobei das Unternehmen ein Einzelhandelsunternehmen ist und die externen Betriebssysteme aufweisen: ein Merchandising-Planungssystem; ein Ergänzungsplanungssystem; ein Auftragsverwaltungssystem; und ein Logistik- und Vertriebssystem.
Software nach Anspruch 99, wobei die externen Betriebssysteme eines oder mehrere aufweisen aus: externe Unternehmenslösungskomponenten, die dem Unternehmen zugeordnet sind; und externe Unternehmen.
System zur zentralen Verwaltung von Kernunternehmensreferenzdaten, die einem Unternehmen zugeordnet sind, aufweisend: Mittel zur Bereitstellung eines zentralisierten Stammdepots, das die Kernunternehmensreferenzdaten enthält; Mittel zur Bereitstellung eines internen Dienstegefüges, das mit dem zentralisierten Stammdepot verbunden ist und interne Dienste für die Verwaltung der Kernunternehmensreferenzdaten im zentralisierten Stammdepot zur Verfügung stellt, wobei einer oder mehrere der internen Dienste direkten Zugriff auf die Kernunternehmensreferenzdaten haben, die zu Verwaltungszwecken im zentralisierten Stammdepot gespeichert sind; und Mittel zur Bereitstellung einer Infrastrukturdienstebene, die mit dem zentralisierten Stammdepot verbunden ist und Massendatentransfers von Kernunternehmensreferenzdaten zwischen dem zentralisierten Stammdepot und einem oder mehreren externen Betriebssystemen entsprechend einem oder mehreren Geschäftsabläufen auf Unternehmensebene zur Verfügung stellt, wobei den externen Betriebssysteme indirekten Zugriff auf die zu Betriebszwecken im zentralisierten Stammdepot gespeicherten Kernunternehmensreferenzdaten gestattet ist.