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
So allgemein wie möglich und so spezifisch wie nötig
Alle Facility-Typen und ihre Elemente allgemein wie möglich zu gestalten, bedeutet, dass sie für so viele Anwendungsfälle wie möglich einsetzbar sind. Das bedeutet, dass zum Beispiel ein 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.
Beispiel: Facility "Büro" einrichten geht als Facility-Typ "Raum", weil es ein Raum ohne besondere Anforderungen ist
Die Facility-Typen und ihre 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: "Kühlkammer" hat mehr Anforderungen als in "Raum" gegeben sind, deshalb verdient es einen eigenen Typen
"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.
Kontrolliere, ob ein neuer Type wirklich notwendig ist!
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. Dann kann dieser Facility-Typ für die Kaffeemaschine benutzt werden. Wird eine neue Eigenschaft benötigt, wie zum Beispiel "Sorte der Kaffeebohnen", sollte ein neuer Typ angelegt werden.
Nutze die Vererbung weise!
Eigenschaften werden immer von übergeordneten an untergeordnete Facility-Typen vererbt. So können allgemeine Eigenschaften an speziellen Typen wiederverwendet werden. Deshalb sollten Sie so weit oben wie möglich den der Hierarchie eingesetzt werden.
Beispiel: Beim Facility-Typen "Elektrozähler wird die Eigenschaft "Geeicht bis" benötigt. Diese Eigenschaft wäre aber findet auch an den übergeordneten Typen "Zähler" und all seinen anderen untergeordneten Facility-Typen Verwendung. 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.
Nutze Meanings um Daten zu separieren!
Wenn es notwendig ist, Daten separiert voneinander zu aggregieren, werden auch separate Meanings benötigt.
Beispiel:
- z.B. Lastgang Erdgas/ Elektro/ etc.
Hinweise zu Eigenschaften
Gruppiere Eigenschaften sinnvoll!
Eine sinnvolle Gruppierung von Properties macht die Eigenschaftenseite an Facilities übersichtlicher, hilft dem Nutzer dabei, diese einzutragen und erleichtert die Zuordnung.
Beispiel: Technische Daten eigene Gruppe, Allgemeines eigene, Abmessungen eigene, vor allem sinnvoll bei vielen Eigenschaften
Vereinfache die Facility-Suche!
Ist eine Eigenschaft als "searchable" markiert, dann kann deren zugehörige Facility in QBRX über die Suche gefunden werden. Eigenschaften sollten als "searchable" markiert werden, wenn es dabei hilft, facilities zu finden. Es sollte jedoch nicht jede Eigenschaft markiert werden, da sonst unnötig viele Suchergebnisse geliefert werden. Die Funktion sollte auch nur bei Eigenschaften verwendet werden, deren Wert eindeutig von anderen unterscheidbar ist.
Beispiel: Adressen von Standorten oder Herstellern von Ausrüstungsteilen sind beispielsweise sinnvoll.
Benennung
Namen konsistent und eindeutig wählen!
Eine eindeutige Benennung erleichtert es dem Nutzer, den richtigen Facility-Typen und dessen Elemente auszuwählen und danach zu filtern. Dabei sollte man sich an vorher festgelegte Konventionen halten um eine gewisse Konsistenz zu gewährleisten.
Damit diese eindeutig und konsistent benannt werden, sollte vorher eine dementsprechende Einigung getroffen werden, die in einer Dokumentation festgehalten wird.
Abkürzungen vermeiden!
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.