Lade...
 

Grammatik der Unternehmensmodellierung

Seitenaktionen
Drucken

Grammatik der Unternehmensmodellierung

Einleitung

Die hier vorgestellte „Grammatik“ soll ein kurzer, zusammenfassender Leitfaden des CyberEnterprise Unternehmensmodells sein. Die einzelnen Aufzählungspunkte sollten immer im Zusammenhang mit den vorherigen Abschnitten gesehen werden.

Informationsmodelle

  • Informationsmodelle sind zunächst nur rein sprachlich gebildete Strukturen aus Worten/Phrasen.
  • Folglich gehorchen Informationsmodelle den üblichen grammatikalischen Kategorien natürlicher Sprachen. (Beispiel: Firmen, Teile, Ausgangsrechnungen, Datum sind Substantive, addieren, subtrahieren, berechnen sind Verben,  frühester, niedrigster, maximaler sind Adverben oder Adjektive)
  • Jede Informationseinheit eines Informationsmodells muss demnach rein sprachlich exakt beschreibbar sein.

Datenfelder, Entitäten und Relationen

  • Datenfelder sind die kleinsten Informationseinheiten eines Informationsmodells.
  • Daten(felder) werden aus einfachen und/oder komplexen Datentypen (Objekten) gebildet. (Beispiel: Text (STRING, MULTIPLE_STRING), relle Zahlen mit oder ohne Einheit (INTEGER, CX_NUMERIC, CX_FLOAT, CX_VALUE), Datum (CX_DATE, CX_SPAN_DATE, CX_PERIODIC_DATE))
  • Daten(felder) werden zu semantisch zusammengehörenden Entitäten (Klassen) gruppiert. (Beispiel Person CX_PERSON, Teil/Artikel CX_ITEM)
  • Entitäten sind je nach Nutzung in ihrer Gültigkeit einschränkbar (Validity, Security, Domains).
  • Entitäten sind um beliebige Entitäten, Daten(felder) und/oder Relationen erweiterbar (Container Prinzip, Slots).
  • Relationen zwischen Entitäten sind grundsätzlich als gegenseitg anzusehen (back references), können aber aus rein technischen Erwägungen heraus nicht so implemetiert sein.
  • Existenz oder Nicht-Existenz von Daten(feldern), Entitäten und/oder Relationen in einer Entität hat per se einen eigenen Informationsgehalt.
  • Relationen selbst sind in ihrem Informationsgehalt erweiter- oder veränderbar (Wrapper Konzept, Beschreibung der Kante).
  • Entitäten, deren Daten(felder) und die Relationen zu anderen Entitäten werden mit Hilfe eines DV-Systems definiert und manipuliert.

Unternehmensmodell

  • Ein Unternehmensmodell definiert ein (technisch) grundlegendes aber (geschäftsorientiert) eingeschränktes oder erweiterbares Beziehungsgeflecht zwischen Entitäten.
  • Das (technische) Beziehungsgeflecht dieser (technisch) unterschiedlichen Entitäten ist unabhängig von seiner Nutzung.
  • Ein use-case definiert nur den Umfang der Nutzung und den „View“ auf Daten(felder) und deren Relationen untereinander, nicht aber seine (technisch) grundlegende Struktur.
  • Gleiche (technische) Entitäten können in ihrer (geschäftsorientierten) Nutzung unterschieden werden (Konzept der Pseudoklassen).
  • Entitäten eines Unternehmensmodellls werden (technisch) unterschieden in Informationsdaten (Basis Objekte) , Stammdaten (Geschäftsobjekte), Bewegungsdaten (Transaktionen (OLTP)) und Konten (Datenwürfel (OLAP)).

Stammdaten

  • „Stammdaten“ werden unterschieden in „reale Dinge“ (materiell, tangible) und „Begriffe“ (immateriell, non-tangible).
  • „Begriffe“ stehen für sich selbst  oder haben eine Beziehung zu „realen Dingen“. Hierbei  erfüllen Sie die Aufgabe, die Eigenschaften/Funktion realer Dinge zu beschreiben (Rollenkonzept). (Beispiel: Firma (materiell)/Kunde (immateriell), Gebäude (materiell)/Lager (immateriell))
  • „Reale Dinge“ können mit beliebig vielen „Begriffen“ in Beziehung stehen und/oder um beliebig viele „Begriffe“ erweitert werden.
  • "Begriffe" können(sollten mit anderern "Begriffen" nur dann in Beziehung stehen, wenn die "Begriffe" zueinander orthogonal sind. (Beispiel: Kostenstelle / Lager)
  • „Stammdaten“ sind kategorisierbar/strukturierbar. (Beispiel: Firmen nach Verkaufsgebieten, Artikel nach Artikelgruppen)
  • „Stammdaten“ werden mittels „Informationsdaten“ genauer beschreiben. (siehe Abschnitt Datenfelder, Entitäten und Relationen)
  • „Stammdaten“ bilden den Fokus für „Bewegungsdaten“.
  • „Stammdaten“ können beliebig viele, aus unterschiedlichen Verarbeitungsaspekten definierte „Konten“ (Monitore) besitzen, die die entsprechenden„Bewegungsdaten“ halten. (Beispiel: Fibu-Konto mit Journaldaten, Kunden-Umsatzkonto mit Ausgangsrechnungen)

Bewegungsdaten

  • „Bewegungsdaten“ sind regelbehaftet ein- und ausbuchbar (Geschäftslogik).
  • „Bewegungsdaten“ verändern bei jedem Buchungsvorgang den Zustand und die Konten von mit ihnen in Beziehung stehenden „Stammdaten“ mittels der über die „Bewegungsdaten“ erreichbaren Daten(felder) (Geschäftsprozess I). (Beispiel Transaktions(regel)beschreibung für Wareneingansbeleg: Menge geliefert erhöht den Bestand eines Artikel-Lagerkontos)
  • „Bewegungsdaten“ verändern bei jedem Buchungsvorgang ihren eigenen Zustand (Geschäftsprozeß II). (Beispiel: Auftragsstatus: eröffnet, abgegeben, beauftragt, storniert)
  • „Bewegungsdaten“ haben „Bewegungsdaten“ als Vorgänger und Nachfolger (Geschäftsprozess III). (predecessors und successors Relationen)

Konten

  • „Konten“ haben beliebig viele Unterkonten beliebiger Dimensionen, die mittels Regeln automatisch gebildet werden.
  • „Konten“ und deren Unterkonten werden nur mittels Regeln bebucht, d.h. das Setzen und Ändern von Daten(feldern) sowie das Registrieren oder Deregistrieren von „Bewegungsdaten“.
  • „Konten“ und deren Unterkonten unterstützen das „drill-down“ bis hin zu „Bewegungsdaten“. „Konten“ und deren Unterkonten unterstützen das „roll-up“ bis hin zu den sie besitzenden „Stammdaten“.