Die 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! Eine zu allgemein gehaltenes Element hilft auch keinem weiter, da sein Anwendungszweck zwar universell, aber dennoch zweckdienlich sein muss.
Beispiel: "Temperatur" wäre beispielsweise kein gutes Meaning an einem Standort, da man nicht wissen kann, worauf es sich bezieht. Ist damit die Raum- oder Außentemperatur gemeint? Da man nur ein Meaning der selben Art pro Facility haben kann, muss man hier spezifischer werden und das Meaning "Außentemperatur" anlegen und an einer untergeordneten Facility für einen Raum die "Raumtemperatur" nutzen.
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 bi" 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, zum Beispiel "Sorte der Kaffeebohnen".
Eine Eigenschaft muss höchstmöglich in der Facility-Typ-Vererbung angebracht werden, damit die Vererbung noch Sinn ergibt.
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.
Properties sollten sinnvoll gruppiert sein.
Eine sinnvolle Gruppierung von Properties hilft dem Nutzer dabei, diese 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!
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,
Meanings müssen so benannt werden, dass sie unabhängig voneinander genutzt werden können.
- Keine „Durchnummerierung“ von Meanings.
- Z.B. Temperatur 1,2, 3, …
Abkürzungen sollten vermieden werden 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 sollten, 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.