In der Facility-Bibliothek sind alle Facility-Typen, dazu gehörige Eigenschaften und Meanings hinterlegt.
Damit das System der Facility-Bibliothek funktioniert, welches vor allem von intelligenten Vererbungen innerhalb der Facility-Typen profitiert, ist es wichtig, dass die Bibliothek effizient verwaltet wird.
Deshalb besprechen wir in diesem Artikel in Form eines Best-Practice die wichtigsten Aspekte, die bei der Verwaltung der Facility-Bibliothek zu beachten sind.
Regeln zum Anlegen von Typen, Meanings und Properties
Elemente sollten so allgemein wie möglich und so spezifisch wie nötig gestaltet werden!
Elemente so allgemein wie möglich zu gestalten, bedeutet, dass sie für so viele Anwendungsfälle wie möglich einsetzbar sind.
Beispiel: Das bedeutet, dass zum Beispiel der Typ "Equipment" als übergeordneter Typ so gestaltet sein muss, dass seine dazugehörigen Properties und dazugehörigen Meanings auf so viele Facilities wie möglich übertragbar sind. Durch einen solchen Aufbau kann der Facility-Typ für viele Facilities genutzt werden und kann gleichzeitig problemlos Properties und Meanings an zahlreiche untergeordnete Facility-Typen vererben.
Die Elemente sollten dennoch so spezifisch wie nötig beschrieben werden! Es sollte zwar universell einsetzbar sein, aber trotzdem so spezifisch gestaltet, dass es optimal zu seinem Anwendungsbereich passt.
Beispiel: "Temperatur" wäre as meaning beispielsweise zu allgemein gehalten, weil man als Anwender nicht weiß, welche Temperatur damit gemeint ist. An einem Standort könnte es ja sowohl die Außentemperatur, als auch die einzelner Räume sein. Die Meanings müssen also einzeln angelegt werden, um bestmöglich benutzt werden zu können.
Es sollte nur dann ein neuer Typ erstellt werden, wenn dieser spezifische Einstellungen benötigt, die an keinem anderen Typen gegeben sind.
Einige Facilities sind so spezifisch, dass es notwendig ist, einen eigenen Typen für sie anzulegen, weil sie Einstellungen benötigen, die so nicht durch andere Typen abgedeckt werden. Ist dies nicht der Fall, dann sollte kein neuer Facility-Typ angelegt werden!
Beispiel: Soll eine Kaffeemaschine als Facility angelegt werden, dann ist es durchaus möglich, dass alle dafür notwendigen Eigenschaften wie "Hersteller" oder "Garantie bis" bereits am Typen "Equipment" hinterlegt sind. Erst wenn eine Kombination aus Eigenschaften benötigt wird, die so an keinem anderen Typen zu finden sind, sollte ein neuer Typ angelegt werden, wie zum Beispiel "Sorte der Kaffeebohnen".
Eine Eigenschaft muss höchstmöglich in der Facility-Typ-Vererbung angebracht werden, damit sie effektiv vererbt werden kann.
Eigenschaften werden immer vollständig von übergeordneten an untergeordnete Facility-Typen vererbt. Deshalb sollten Sie so weit oben den der Hierarchie eingesetzt werden wie möglich.
Beispiel: Beim Facility-Typen "Elektrozähler (manuell) gibt es die Eigenschaft "Geeicht bis". Diese Eigenschaft wäre aber auch für den übergeordneten Typen "Elektrozähler" verwendbar, ebenso wie am weiter oben stehenden Typen "Zähler" und all seinen anderen untergeordneten Facility-Typen. Es ergibt jedoch keinen Sinn, die Eigenschaft beim Typen "Equipment" anzubringen, da sie nicht für alle dort untergeordneten Typen gilt. "Geeicht bis" sollte demzufolge beim höchstmöglichen Typen "Zähler" angebracht werden, da es sinnvoll auf alle untergeordneten Typen vererbt werden kann.
Ein neues Meaning sollte erstellt werden, wenn Daten unabhängig von bereits existierenden Meanings aggregiert werden sollen.
- z.B. Lastgang Erdgas/ Elektro/ etc.
Hinweise zu Properties
Properties sollten sinnvoll gruppiert sein.
Eine sinnvolle Gruppierung von Properties hilft dem Nutzer dabei, diese einzutragen und zuzuordnen.
Ein Element sollte als "searchable" markiert werden, wenn es sinnvoll ist, danach suchen zu können.
Ist ein Element als "searchable" markiert, dann kann es in QBRX über die Suche gefunden werden. Das ist zum Beispiel bei Adressen von Standorten oder Herstellern von Ausrüstungsteilen sinnvoll.
Wo noch? Wann nicht?
Benennung von Elementen
Namen müssen konsistent und eindeutig gewählt werden.
Eine eindeutige Benennung von Elementen erleichtert es dem Nutzer, den richtigen Facility-Typen auszuwählen und danach zu filtern. Dabei sollte auch eine gewisse Konsistenz eingehalten werden, die sich an der Benennung der bisher existierenden Typen bzw. der entsprechenden Dokumentation orientiert.
Namen sollten so allgemein wie möglich und so spezifisch wie nötig gewählt werden!
Was für die Gestaltung von Elementen gilt, gilt auch für deren Benennung: Elemente sollten so benannt werden, dass sie für viele Zwecke benutzt werden können, aber so spezifisch, dass klar wird, wofür genau sie da sind.
Beim Erstellen einer neuen Bibliothek sollte vorher eine Einigung zur Benennung getroffen und dokumentiert werden.
Eine neue Facility-Bibliothek erfordert das Anlegen vieler neuer Elemente. Damit diese eindeutig und konsistent benannt werden, sollte vorher eine dementsprechende Einigung getroffen werden, die in einer Dokumentation festgehalten wird.
Das sollten wir auch mal machen 
Meanings müssen so benannt werden, dass sie unabhängig voneinander genutzt werden können.
Meanings sollten an so vielen Facilities wie möglich benutzt werden können und daher, wie alle anderen Elemente auch, zwar spezifisch, aber dennoch so allgemein wie möglich benannt werden. Dazu gehört auch, dass sie unabhängig voneinander funktionieren müssen.
Beispiel: Gibt es mehrere Temperaturen, die an einer Facility erfasst werden müssen, dann sollte diese eindeutig benannt werden. Beispiel mit den Temperaturen 1,2,3 erklären, wo kam das noch mal vor?
- Keine „Durchnummerierung“ von Meanings.
- Z.B. Temperatur 1,2, 3, …
Abkürzungen sollten vermieden und nur in Ausnahmefällen bei unzweifelhaft, allgemein bekannten Bedeutungen verwendet werden.
Es gibt Abkürzungen, die allgemein bekannt sind und von jedem verstanden werden, wie zum Beispiel "z.B.". Es gibt allerdings auch Abkürzungen, die zwar praktisch erscheinen, aber aufgrund ihrer Unbekanntheit oder Doppeldeutigkeit mehr Probleme verursachen als lösen. Nicht jeder kennt die Abkürzung "NTH" für "nice to have". Stattdessen könnte sie auch als "Nothing" oder "No Therapy Helpful" gedeutet werden.
Im Zweifelsfall sollte immer davon ausgegangen werden, dass die Bedeutung einer Abkürzung nicht bekannt ist! Bei Unsicherheit ist ein Test an mindestens fünf unabhängigen Personen mit unterschiedlichem demographischen Hintergrund durchzuführen und zu verifizieren. Oder man schreibt das Wort einfach aus.