CW: Herr Dr. Oelschlegel, was war der Anlass für das Projekt?

Ich bin seit etwa 20 Jahren im Computer Aided Facility Management (CAFM) tätig. Während der Arbeit an meinem Buch über CAFM analysierte ich die jährlich erscheinende Software-Übersicht zum Facility Management, in der etwa 30 Hersteller ihre Produkte präsentieren. Die Produkte werden gemäß den Richtlinien 940 der GEFMA - das ist der Deutsche Verband für Facility Management - beschrieben. Dabei stach mir die verwendete "Kreuzellisten-Methode", die auch in anderen Sparten wie ERP oder DMS üblich ist, ins Auge. Das missfällt mir schon lange.

Nicht korrekte Begrifflichkeit

CW: Was stört Sie dabei konkret?

Beispielsweise ist oftmals die Begrifflichkeit klassifikatorisch nicht korrekt, und es werden mehrfachinterpretierbare Begriffe verwendet. Was nicht in die Klassifikation passt, wird unter "Sonstiges" subsumiert. Dies habe ich in meinem Buch kritisiert und mit Beispielen belegt. Da ich meist versuche, Kritik mit Gegenvorschlägen zu verbinden, hat sich in mehr als einjähriger Modellierung etwas ergeben, von dem ich selbst überrascht worden bin: ein komplexes Datenmodell über Applikations-Software, umgesetzt in einer objekt-relationalen Datenbank.

CW: Gibt es denn bei CAFM spezifische Probleme und wie sehen die aus?

Die Beschreibungs-Probleme sind nicht CAFM-spezifisch, sondern allgemeiner Natur. Die Software-Hersteller entwickeln ihre Daten- und Funktionsmodelle immer weiter über die Kernfunktionalität der Applikation hinaus. So entstehen "eierlegende Wollmilchsäue" mit allen Vor- und Nachteilen für den Anwender. Erstens verwischen die Grenzen zwischen ERP, CRM, DMS, ECM etc. immer mehr - ein Sachverhalt, der weder durch Suchmaschinen noch durch Vermarktungsplattformen wie Softguide, oder Spartendatenbanken zum ERP, ECM und PMS wie bei BARC, abgebildet wird. Zweitens wird oft nicht klar, was eine gefundene Software im Vergleich zu ähnlichen Produkten auszeichnet oder welche Merkmale der Anwendungs-Software wesentlich und welche unwesentlich sind. Und ein dritter Punkt: Ausschreibungen zur Funktionalität von Anwendungs-Software sind bis dato entweder zu detailliert oder zu grob und damit mehrdeutig. Dieser Zustand resultiert aus der Situation, dass es bisher kein übergreifendes Datenmodell über Anwendungs-Software gibt - weder national noch international.

Branche spielt herausragende Rolle

CW: Welche Rolle spielt denn die Branche in Ihrem Modell?

Ich gehe davon aus, dass es sehr unterschiedliche Sichtweisen bei der Anschaffung oder Erneuerung einer Applikation gibt. Ein Top-Entscheider auf strategischer Ebene hat andere Kriterien als der potenzielle Nutzer auf operativer Ebene und der wieder andere als der IT-Verantwortliche des Unternehmens. Anwendungs-Software spiegelt immer die Begrifflichkeit und Funktionalität der Anwendung wider. In diesem Sinne spielt die Branche, in der die Software angewendet wird, eine herausragende Rolle.

CW: Das Problem scheint dabei die Begrifflichkeit zu sein und die geringe Standardisierung.

Ja. Es geht in meinem Ansatz darum, Anwendungs-Software unter obigen Gesichtspunkten objektiver zu klassifizieren, die Beziehungen zwischen Applikationen deutlich zu machen und so zu beschreiben, dass man Produkte findet, die die geforderte Funktionalität erfüllen. Das soll unabhängig davon sein, welchem Akronym -GIS, ERP, AVA, PLM, AGVS etc - der Hersteller seine Software zugeordnet hat. Die standardisiert beschriebenen Dienste - die Objektinformation der Software-Beschreibung - und die definierten Dienstleistungen - die Metainformation über die Software - können entsprechend den funktionalen Anforderungen Basis für Ausschreibungen sein.

CW: Wie ist denn der Zusammenhang zum Datenmodell?

Über diese Begrifflichkeit, mit der sich die funktionalen Anforderungen zum Management von Facilities mittels IT-Unterstützung beschreiben lassen, bin ich auf ein verallgemeinerbares Datenmodell gekommen. Die Verallgemeinerung resultierte auch daraus, weil CAFM sich durch viele möglichen Schnittstellen zu anderen Applikationen wie ERP, DMS, EMS oder GIS auszeichnet. Aber ohne meine jahrelange IT-Erfahrungen auf Gebieten wie CAD im Bauwesen und Maschinenbau, PMS (Projektmanagement-Software), GIS (Geoinformationssysteme), ERP, DMS sowie AVA (Ausschreibung Vergabe Abrechnung im Bauwesen) wären mir sicherlich diese Ideen nicht gekommen. Interessanterweise haben einige CAFM-Hersteller bei der gemeinsamen Datenübernahme das Datenmodell für die Dokumentation ihrer Software geeigneter als ihre bisherige Beschreibung gefunden.

Das Datenmodell

CW: Das Datenmodell steht also im Zentrum Ihres Projekts.

Ja. Ich habe ein Datenmodell entwickelt, mit dem man beliebige Anwendungs-Software durch spartenspezifische und spartenübergreifende Basisdienste beschreiben kann. Entsprechend ersten Erfahrungen gibt es in jeder Sparte 20-30 spartenspezifische Dienste. Im CAFM zum Beispiel den Winterdienst oder die Schlüsselverwaltung. Hinzu kommen vorerst etwa 50 spartenübergreifende Basisdienste. Das sind beispielsweise Adressverwaltung oder Dokumentenverwaltung. Die Dienste, die zu einer Dienstleistung gehören, werden von Experten definiert. Diese Dienstleistungen werden häufig mit Management bezeichnet. Beispielsweise Reinigungs-Management, Schließ-Management, Adress-Management oder Dokumenten-Management. Keiner Applikation wird in meinem Daten- und Funktionsmodell automatisch ein Management-Begriff zugeordnet. Das ist ein Metabegriff, der sich durch die Beziehung zwischen den Diensten und deren Vorhandensein regelbasiert ergibt. Damit bestimmen die Objektdaten, welches Akronym sich eine Applikation anheften kann. Bisher macht dies ausschließlich der Hersteller. Deshalb spielt in meinem Datenmodell der Unterschied zwischen Objekt- und Metadaten eine wesentliche Rolle. Mit wenigen Objektdaten, die in m:n-Relationen verknüpft sind, lassen sich somit sehr viele Metadaten gewinnen, deren Beziehungen sich in Begriffsnetzen grafisch abbilden lassen.

CW: Die Metadaten werden also aus den Objektdaten automatisch generiert?

Im Unterschied zu den am Markt befindlichen Software-Vergleichen werden von den Software-Produkten weitestgehend Objektdaten - etwa 50 Merkmale - erfasst und daraus über Regeln Metadaten gebildet. Die zwischen den Begriffen bestehende Logik wird für Algorithmen genutzt, um weitestgehend fehlerhafte Angaben über eine Software auszuschließen. Ein potenzieller Nutzer der operativen Ebene kann zum Beispiel einfach nach Funktionalitäten beziehungsweise Diensten suchen und bekommt dann eine Menge von Software-Produkten angeboten.

Objekt- und Metainformation

CW: Was heißt das konkret?

Das Thema Objekt- und Metainformation möchte ich an dem scheinbar trivialen Begriff "Branche" erläutern. Der Begriff "Branche" wird nach meiner Beobachtung in jeder Anwendungs-Software abgebildet. Ich habe bisher allerdings noch keine zwei Software-Produkte gefunden, bei denen dieser Begriff identisch genutzt wird. Das ist für Top-Entscheider bei der Software-Auswahl ein Ärgernis, aber wiederum verständlich, denn jeder Hersteller versteht darunter das, was aus dem Fokus seiner Kernfunktionalität resultiert. Dieses begriffliche Dilemma konnte ich durch einen Trick lösen.

CW: Und der wäre?

Das Bundesamt für Statistik veröffentlichte den Wirtschaftszweigeschlüssel WZ 2008. Die IHKs haben diesen Schlüssel erweitert und nutzen ihn als Basis für die monatliche Analyse der Wirtschaftsentwicklung der BRD. Der WZ 2008 besteht aus fünf Klassifizierungsebenen mit 21 Entitäten, Abteilung, Gruppe, Klasse und Unterklasse mit je 176, 272, 615 und 839 Entitäten von Wirtschaftzweigen. In meinem Datenmodell ist die Branche genau die Klassifizierung aus einer der fünf möglichen Ebenen.

Die Zuordnung einer Branche zu einem Software-Produkt ist dann Objektinformation, wenn der Hersteller Referenzkunden angibt. Jeder Referenzkunde hat genau eine WZ 2008-Zuordnung - zum Beispiel Krankenhäuser - Kode: Q.86.1. Damit hat diese Information zwei Eigenschaften: direkt mit dem Objekt (Software) verbunden zu sein (Objektinformation) und auch noch objektiv, also frei von einer Meinung zu sein. Natürlich ordnet auch ein Hersteller seine Software in den WZ 2008-Schlüssel ein - also zum Beispiel in die "Abwasserentsorgung" (E.37) oder "Altenheime; Alten- und Behindertenwohnheime" (Q.87.3.0). Diese Zuordnung des Herstellers ist eine Aussage über das Produkt, also eine Metainformation. Eine gewisse Zwischenstellung ergibt sich dann, wenn der Software-Hersteller Verkaufsmodule für Branchen bündelt. Solche Bündelungen geben relativ objektive Informationen über die Branche, auf die sich die Software spezialisiert hat.

Zusammenhang in Begriffsnetzen

CW: Sie sprechen auch von einem Begriffsnetz. Was hat es damit auf sich?

Im Zuge der Datenmodellierung musste ich neue Begriffe bilden. Es hat mich schon überrascht, dass es für die Akronyme der IT, die in aller Munde sind, ständig erweitert und modifiziert werden, keinen Oberbegriff gibt. Ich habe dafür das Wort Sparte benutzt. Innerhalb einer Sparte gibt es typische Funktionalitäten, die ich als Spartendienste bezeichnet habe. Jede Sparte benötigt aber auch Dienste, die nicht zu deren Kerngeschäft gehören. ERP benötigt beispielsweise eine Adressverwaltung. Adressverwaltung ist aber auch eine Kernfunktionalität von CRM. Über m:n Tabellen können solche Beziehungen sehr gut abgebildet werden. Diese Beziehungen lassen sich dann grafisch aufbereiten und ergeben anschaulich in Begriffsnetzen die Zusammenhänge, zum Beispiel zwischen den Sparten und Spartendiensten.

CW: Inwieweit bilden Sie damit auch IT-Funktionalitäten ab?

Bisher habe ich über die Begrifflichkeit aus Nutzersicht gesprochen. Genau das gleiche Vorgehen war notwendig, um die IT-spezifische Funktionalität von Software abzubilden. Hierfür wurden Begriffe wie Software-Dienst (Mandantenverwaltung, Mehrsprachigkeit, Replikation usw.) definiert und mit gängigen Begriffen wie Schnittstellen verbunden. Der häufig benutzte Begriff Modul wurde im Begriff Verkaufsmodul mit entsprechenden Attributen präzise definiert.

Für die Investitionssicherheit einer Applikation spielen die Software-Entwicklungstools eine wesentliche Rolle. Ebenso wird auch das Thema Open Source im Datenmodell berücksichtigt. Insgesamt hat sich ein sehr komplexes Datenmodell ergeben, das an der Sparte CAFM verifiziert und an mehreren Sparten testweise erprobt worden ist.

Einbruch in etablierten Markt

CW: Haben Sie vor, die Datenbank zu vermarkten?

In meinen 40 Jahren beruflicher Tätigkeit war ich die Hälfte wissenschaftlich und nach 1990 unternehmerisch im CAD-Systemhaus tätig. Die Umsetzung der prototypischen Entwicklung der Software-Datenbank in ein Produkt erfordert erhebliche Manpower, weitere wissenschaftliche Arbeit und Zusammenarbeit mit und zwischen Verbänden der Sparten. Den Prototyp habe ich an der TU Dresden, der FH Erfurt und der HTW Dresden mit überaus positiver Resonanz vorgestellt. Aber es gibt mindestens zwei Hindernisse: 1.Man muss erheblich investieren. 2. Die Software-Datenbank bricht in einen etablierten Markt ein, in dem Umsatz vor allem durch Verlage gemacht wird.

CW: Ihr Ansatz wäre ein kostenloser?

Im Prinzip ja. Mir gefällt das Geschäftsmodell von XING, weil sich Nutzen und Aufwand lohnen: einfache Nutzung, kostenfrei, komplexe Nutzung muss bezahlt werden. Es gibt kaum Datenbanken, in die der Software-Hersteller kostenlos seine Produkte einstellen kann. Dadurch gibt es keine vollständige Übersicht für den Nutzer. Die Software-Datenbank könnte auch für die sich immer mehr verbreitende Zertifizierung von Applikationen genutzt werden. Damit würde zum Beispiel die GEFMA 444 - das ist die Zertifizierung von CAFM - statt auf deklarativen Kriterien auf ein generisches Datenmodell aufbauen.

Die Zukunft könnte so aussehen: Die Datenbank hat ein Potenzial von mehreren tausend nationalen und internationalen Software-Produkten. Es soll ein Webportal (www.diesoftwaredatenbank.de) geben, wo jeder Applikationshersteller sein Softwareprodukt kostenfrei selbst pflegt. Kunden benutzen die Datenbank je nach Nutzerprofil für Software-Produktrecherchen, Preisanfragen und Ausschreibungen. Die Nutzung reicht von der kostenfreien "Schnupperrecherche" bis zur kostenpflichtigen funktionalen Ausschreibung.