Zweifellos fördern unternehmens weite Datenmodelle die Software-Integration. Von diesem Standpunkt aus skizziert Peter Walleitner* den Aufbau eines Datenmodells sowohl für Groß- als auch für Kleinunternehmen und schildert die auftretenden Probleme.
Der Nutzen von Datenmodellen als DV-neutrale Vorstufe zu stabilen, DV-orientierten Datenstrukturen (Datenbank-Schemata), ist unbestritten. An dieser Stelle soll die Frage nach der Weite des Horizonts von Datenmodellen, das heißt nach dem "Wie groß"?, nicht nach dem "Wieso überhaupt?, gestellt werden. Ein unternehmensweiter Horizont ist verlockend, fördert er doch die Idee der Erreichbarkeit global in sich stimmiger Datenstrukturen.
Bei der Frage nach der Weite des Horizonts ergeben sich weitere Fragen, in erster Linie nach dem maximal handhabbaren Umfang eines Datenmodells, ferner nach der Beobachtbarkeit der Evolution von Strukturen bei sehr großem Umfang.
Gewaltige Unterschiede gibt es bereits beim Verständnis des Begriffs "Unternehmen". Es reicht vom Einmann-Betrieb bis zum Großunternehmen mit Hunderttausenden von Mitarbeitern, von der monolithischen Spezialbehörde bis zum Mischkonzern, dessen Teile außer der Klammer Kapital kaum weitere Kohärenz aufweisen.
Ein Datenmodell läßt sich auffassen als Bestandteil eines Unternehmens-Gesamtregelwerks, wobei das, was in das Datenmodell einfließt, auf jeden Fall zu den längerlebigen Regeln gehören sollte. Der Umfang des Datenmodells hängt wesentlich vom Umfang des Gesamtregelwerks ab. Und wovon hängt der Umfang des Gesamtregelwerks ab? Zu den Faktoren gehören in erster Linie die Homogenität beziehungsweise Heterogenität der unternehmensspezifischen Geschäftsfelder, danach erst die Unternehmensgröße, ausdrückbar in Kennzahlen wie Jahresumsatz, Mitarbeiterzahl und geografischem Marktumfang.
Ein unternehmensweites Datenmodell muß überschaubar und handhabbar bleiben. Diese Forderung kann erfüllt werden, wenn folgendes gilt:
- Das Gesamtregelwerk als solches ist noch klein (embryonales Unternehmen), oder
- man filtert Grob-Regeln heraus (embryonales Datenmodell), während Detailregeln zurückgestellt werden.
Beide Aspekte werden im folgenden gesondert betrachtet.
Das embryonale Datenmodell ist noch unabhängig vom Umfang des unternehmensspezifischen Gesamtregelwerks - und damit noch unabhängig von Unternehmensgröße und Homogenität der Geschäftsfelder.
Das embryonale Datenmodell stellt so etwas wie ein Geflecht von Grundbegriffen der BWL dar. Es sind noch keine Branchenkonturen erkennbar, geschweige denn unternehmensspezifische Konturen. Man könnte es auch in Diagrammform als Anhang in ein Betriebswirtschafts-Lehrbuch einbringen.
Verschiedene Versuche haben ergeben, daß man auf diese Weise auf zirka 20 bis 40 grundlegende Entities kommt. Die Anzahl der Beziehungen zwischen Entities entwickelt sich ungefähr proportional zu ihrer Menge. Ein embryonales Datenmodell enthält noch keine aussagekräftigen Grundregeln der Beziehungen, keine Aussagen zu Entity-Ids (Identities)
und keine Attribute, geschweige denn Attribut-Wertebereiche.
Auch ein Kleinstunternehmen mit unbedeutendem Mengengerüst braucht einen Grundvorrat an Regelwerk und damit auch an Datenstruktur. Anders betrachtet: Daten sind Gedächtnisinhalte; ein Datenmodell ist eine Strukturierungshilfe für das Gedächtnis.
Als erste Strukturierungshilfe mag das vorhin skizzierte embryonale Datenmodell dienen. Jedoch auch ein Kleinstunternehmen muß konkrete Festlegungen vornehmen über Entity-Ids ("Soll ich als Einmann-Betrieb mit Kunden-Nummern, Rechnungs-Nummern etc. arbeiten?"), über grundsätzliche Beziehungen sowie über Attribute und deren Wertebereiche. Als Speicherungsszenarien kann man sich Karteikästen oder PC-Software Ó la Dbase vorstellen. Während bei der Karteikastenvariante zum Beispiel die Wertebereichs-Festlegungen nicht ganz so streng sind, muß man sich bei der Softwarevariante bis ins Detail festlegen.
Im Folgenden denken wir an bereits ausgewachsener Unternehmen. Die Weiterentwicklung bezieht sich auf das Datenmodell. Sie äußert sich zunächst im Sichtbarwerden von Branchenkonturen (sogenanntes Branchen-Datenmodell). Dies kann durch begriffliche Differenzierung von "Produkt" und in der Folge auch der weiteren betriebswirtschaftlichen Grundbegriffe (siehe Abbildung 1) geschehen.
Die Anzahl der Entities und der Beziehungen zwischen ihnen erhöht sich vielleicht um den Faktor drei bis fünf. Entity-Ids treten dennoch kaum auf, es sei denn, die Branche habe hier genügend einheitliche Spielregeln hervorgebracht. Beispielsweise dürfte im Datenmodell der Automobilbranche von Fahrgestellnummern oder bei Banken von Kontonummern die Rede sein.
Die Branchenkonturen bilden erst eine Zwischenstufe zu einem unternehmensspezifischen Datenmodell, das als Ausgangspunkt einer Transformation in ein Datenbank-Schema dienen kann. Eine weitere Differenzierung der Begriffe und eine Anreicherung mit Details wird erforderlich. Methodisch gesehen äußert sich dies unter anderem in der Bildung von Typ-Hierarchien, Bildung von Entities aus Beziehungen und aus Attributen heraus. Das heißt, Beziehungen können zu Entities werden; Attribute können zu Entities werden.
Letztlich benötigen wir eine komplette Sammlung von Datenelementen mit Wertebereichen. In der Gesamtheit der Datenelemente sind diejenigen, die als Ids der Haupt-Entities dienen (Dinge wie Kundennummern, Auftragsnummern, Produktnummern,... ) die wichtigsten. Man kann sie als "Fixsterne" ansehen, um die sich Planeten-Datenelemente gruppieren. Es ist von großer Bedeutung, wenigstens einige solcher Fixsterne von unternehmensweiter Leuchtkraft definieren zu können.
Durch die Hinzufügung der Details nimmt die Gesamtzahl der Begriffe stark zu. Meist würde der Umfang des Datenmodells die unternehmensweite Handhabbarkeit sprengen (siehe Abbildung 2).Ferner tritt vermutlich die Re-Engineering-Problematik - das heißt die DV-technisch "nichtgrüne Wiese"- in Erscheinung. Der Horizont des Datenmodells muß sich deshalb auf bestimmte kohärente Geschäftsfelder (Sparten) des Unternehmens beschränken. Oder der Horizont wird auf konkrete Anwendungssoftware-Projekte eingegrenzt. Man spricht dann vom Datenmodell der Sparte X oder des Projekts Y.
Beobachtbarkeit evolutionärer Strukturen
Wer einen Sonnenaufgang malen will, kann zwar schnell eine Skizze anfertigen; bis das Gemälde jedoch fertig ist, steht die Sonne bereits ganz woanders. Ähnlich ergeht es oft umfangreichen Planungen, deren Planungsgrundlagen sich permanent verändern. Wenn man das unternehmensweite Datenmodell-Gemälde an einem Rand vonendet hat, ist es an einem anderen Rand womöglich bereits überholt. Auch könnte ein bestehendes unternehmensweites Detail-Datenmodell durch ein Ereignis wie eine Unternehmensfusion mit schnell durchgezogenen organisatorischen Umbauten plötzlich hoffnungslos veraltet sein. Gültig bliebe nur sein embryonaler Urzustand. Datenelemente, die bisher Fixsterne waren, werden eventuell zu Planeten, und die Software-Himmelsmechanik stimmt nicht mehr. Datenstrukturen und Programme sind, eben im Gegensatz zu Mitarbeitern, nicht einfach umerziehbar.
Ein unternehmensweites Datenmodell bleibt prinzipiell auch in Betrieben mit riesigem Gesamtregelwerk stets konstruierbar, sofern man sich auf die embryonale Form des Datenmodells beschränkt.
Wenn man in der Datenmodell-Entwicklung bei Branchenkonturen nicht stehenbleiben kann oder will (die Konsequenz hieße sonst: Standard-Software einsetzen), tritt das Problem der Beobachtbarkeit umfangreicher wachsender Strukturen in Erscheinung. Die Konsequenz dieses Problems lautet: Beschränkung eines Detail-Datenmodells auf einen Ausschnitt im Unternehmen, sei es sparten- oder projektbezogen. Dennoch lohnen sich auch auf Detailebenen, zum Beispiel auf der Ebene der Datenelemente, einige unternehmensweit leuchtende Fixsterne.