Im ersten Beitrag dieser kleinen Low-Code-Gebäudemanagement-Serie, Facility-Management mit Low Code (1): den Bestand abbilden, ging es um das Thema „Stammdaten-Struktur als Datengerüst“. Anhand von zwei Beispielen, einer Liegenschaftsverwaltung für Mietshäuser mit Ninox und einem Verzeichnis der Bauwerke und technischen Anlagen einer Biogasanlage mit Citrix Podio, wurde gezeigt, wie ein hierarchisches Datenmodell hilft, Stammdaten zu strukturieren, in Ordnung zu halten und Objekte zu finden; Informationen und Zahlen in Erfassung und Auswertung bestmöglich zuzuordnen und Mitarbeitern so genau wie möglich mitzuteilen, wo etwas zu tun ist.
Dieser Beitrag handelt von einer App zur Einsatzplanung im Facility-Management, d.h. zur Organisation von Tätigkeiten wie turnusgemäßen Wartungen und Reparaturaufträgen, der Einsatzplanung für Techniker, Hausmeister, Gärtner, Reinigungskräfte. Geklärter Einsatzort dank Datenmodell – aber wie kann man Mitarbeitern am besten mitteilen, was zu tun ist und wer es wann tun soll? Wo und wie sollen beim Einsatz erhobene Daten hinterlegt werden? Wie dokumentiert man die Abnahme einer Leistung, Objektbegehungen zur Kontrolle von Gebäuden und Außenanlagen, Kontrolle von Dienstleistungen wie Gebäudereinigung und Umbauarbeiten, Kontrolle von Brandschutz, Prüfung von Arbeitsschutz, Einhaltung des Arbeitszeitgesetzes?
In diesem Beitrag kommt Citrix Podio zum Einsatz; alle Features lassen sich aber mit sehr ähnlicher Vorgehensweise gleichwertig auch in Ninox darstellen.
Nun könnte man, wenn man mit Podio arbeitet, versucht sein, das Podio-Feature „Aufgabe“ bzw. „Task“ (jederzeit durch das Tastaturkürzel „T“ aufrufbar) zu nutzen und einfach Podio-Aufgaben am Stammdaten-Eintrag des jeweiligen Einsatzorts zu erstellen . Sprich, wenn in einem Hauskeller ein Zähler ausgetauscht werden soll, geht man zum Eintrag des Hauses und erstellt dort die Aufgabe „Zähler austauschen“ für den, der es tun soll. Dies wiederholt man dann am Eintrag jedes Hauses, in dem auch Zähler ausgetauscht werden sollen.
Nachteil der „Podio-Aufgaben“: sie haben zwar typische Aufgaben-Fähigkeiten wie eine Erinnerungsfunktion und eine Kommentarfunktion, aber sind nicht anpassbar. Im Unterschied zu Einträgen einer App kann man ihnen keine zusätzlichen Felder geben. (Bei Ninox kommt man hier übrigens nicht in Versuchung, weil es dort keine Vergleichbare „Aufgaben-Funktion“ gibt; es wird von vornherein davon ausgegangen, daß Aufgaben „systematisch“ angegangen werden, und das heißt als eigene App)
Welche zusätzlichen Felder könnten denn eine Einsätze-App der Gebäudeverwaltung bereichern? Zum Beispiel:
Alles, was zu tun ist, sollte in den Einträgen einer einzigen “Action App” abgebildet werden. Nur so ist es möglich, den Überblick darüber zu bewahren, was insgesamt zu tun ist, wie weit eine Aufgabenerledigung fortgeschritten ist und so weiter.
Der obige Screenshot zeigt ein Feld „Ort“, das auch „Mieteinheit“ heißen könnte, wenn es nur um Mietwohnungen geht, oder „Maschine“, wenn um einen Produktionsstandort, und ein Feld „Objekt“, d.h. das Haus, in dem sich die Mieteinheit, die Maschine usw. befindet. Dies hat den Vorteil, daß auf beide Felder separat gefiltert werden kann, siehe unten im Abschnitt „Fokus durch gefilterte Ansichten“.
Es gibt aber auch einen Nachteil: um die Verbindungsfelder konsistent zuweisen zu können und in allen gefilterten Ansichten alle relevanten Aufgaben auch zu sehen, dürfen die Verbindungsfelder nie leer sein. Das heißt, auch wenn ein Auftrag das ganze Objekt betrifft (z.B. „Hinweis zu Ablesetermin an der Haustür anbringen“), muß das Feld für die einzelne Einheit mit irgendetwas befüllt werden. Somit benötigt man eine eine generische Pseudo-Wohneinheit z.B. mit der Bezeichnung “ganzes Haus”, was die logische Unterteilung zwischen Objekt und Einheit unterläuft.
Die Verbindung zur Einheit, von Hand eingetragen, kann das automatische Eintragen der Verbindung zum Objekt, zu dem die Einheit gehört, anstoßen. Das beschleunigt das Anlegen eines Auftrags, ein Feld weniger auszufüllen!
Ebenso schnell auszufüllen ist das Einsatz-Formular, wenn Mieteinheiten bzw. Maschinen und die Objekte, in denen sie sich befinden, in demselben Feld referenziert werden können – auch wenn sie in getrennten Apps gepflegt werden.
Dies hat den Vorteil, daß die logische Unterteilung zwischen Objekt und Einheit intakt bleibt, d.h. man benötigt keine Pseudo-Einträge für Objekte in der Einheiten App. Sucht man nach dem Namen eines Objekts, z.B. per Straße und Hausnummer, werden einem sowohl alle Mieteinheiten als auch das ganze Objekt in der Autocomplete-Suche vorgeschlagen, wenn man Straße und Hausnummer in die Bezeichnung des Objekts und der Einheit integriert.
Ein kleiner Vorteil besteht darin, daß man die automatische Befüllung eines zweiten Feldes wie bei der anderen Variante nicht programmieren muß – dafür ist die Datenaggregation zwischen den Stammdaten-Apps komplexer: z.B. die Stunden, die man zur Unterhaltung eines Objekts aufgewendet hat, werden nicht nur an den dem Objekt zugeordneten Einheiten, sondern auch am Objekt selbst auflaufen.
Ein weiterer Vorzug, für die Aufgaben nicht die Podio-Aufgabenfunktion zu verwenden, sondern diesen eine App zu widmen, besteht darin, daß man dann alle Ansichten-Funktionen von Podio nutzen kann. Dasselbe gilt selbstverständlich für Ninox, das ebenso reiche Möglichkeiten bietet, Ansichten zu erstellen.
In der Kopfzeile jeder App finden sich sowohl in Ninox als auch in Podio die Buttons für die Auswahl des Ansichts-Typs (Tabelle und Karten sind meiner Ansicht nach die beiden wesentlichen), Sortierung (nur bei Tabellenansicht), Optionen, d.h. Auswahl der ein- und ausgeblendeten Spalten sowie Filter. Es kann nach jedem Kategoriefeld, jedem Verbindungsfeld, jedem Zahlenfeld und jedem Datumsfeld gefiltert werden, in beliebigen Kombinationen. Dies ist ein mächtiges Werkzeug, um Ansichten für bestimmte Situationen zu schaffen, auf denen nur das zu sehen ist, was für diese Situation wichtig ist. Einige Beispiele:
Dies ist eine Übersicht über zu erledigenden Aufgaben gemäß der Kanban-Methode. Dies läßt sich erstellen, indem man die Ansicht „Kacheln“ und in den Optionen bei „Spalten basieren auf“ ein Status-Feld auswählt. Daraus kann man das persönliche Kanban-Board für jeden Mitarbeiter zu machen, indem man
Man kann in der mobilen App einfach, wie im Screenshot, „Mein Kanban-Board“ aufrufen. Dies hat den Nachteil, daß man auch Aufgaben sieht, die noch im „Eingang“ liegen oder schon in „Abnahme“ sind. Den zusätzlichen Fokus auf tatsächlich anliegende Aufgaben kann man durch weitere Filter schärfen, z.B.
Um möglichst gut schon im Web-Browser zu sehen, was in der mobilen Ansicht erscheint, empfiehlt sich, den Ansichts-Typ „Tabelle“ zu wählen. Wenn man die Einträge nun noch nach Objekt sortiert, so daß der Mitarbeiter alle Einträge eines Objekts direkt untereinander vorfindet, steht dem effizienten Abarbeiten einer Aufgabenliste nichts mehr im Weg.
Die Listen-Ansicht mit ihrer Möglichkeit zu sortieren hilft auch bei der Einhaltung von Fristen, indem man absteigend nach Datum sortiert. Alphabetische Sortierungen oder die Sortierung nach Priorität, Status, Objekt etc. haben jeweils ihren Charme. Will man nach mehreren Kriterien sortieren, kann eine Berechnungsspalte für ein Sortierkriterium hier auch komplexe Wünsche erfüllen.
Im nächsten Beitrag dieser kleinen Gebäudemanagement-Serie wird es darum gehen, Zähler-Ablesungen zu organisieren und nachzuhalten – wenn Abrechnungen zu erstellen sind, ist es wichtig, keinen Zähler zu vergessen, der ablesenden Person das Auffinden des Zählers zu erleichtern, ein „Beweisfoto“ zu dokumentieren, Plausibilitäts-Checks zu erleichtern und daher Zähler und Ablesungen nach Objekt, Einheit, Mieter, Zeitpunkt etc. gruppiert darzustellen sowie die Verbrauchsdaten gleich mit errechnet zu bekommen. Dann fehlt nicht mehr viel zu einer kompletten Nebenkostenabrechnung!
Noch keine Kommentare vorhanden
Was denken Sie?