Facility-Management mit Low Code (2): Einsätze planen, durchführen, dokumentieren

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.

Überblick durch alle Aufgaben an einem Ort

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)

Screenshot Einsatz-App Gebäudemanagement: Zähleraustausch

„Reiche“ Aufgaben-App mit Stammdaten-Kontext

Welche zusätzlichen Felder könnten denn eine Einsätze-App der Gebäudeverwaltung bereichern? Zum Beispiel:

  • Fotos, die vom Mieter geschickt wurden oder bei einer Objektbegehung gemacht;
  • eine Priorität, so daß der Mitarbeiter weiß, wo er zuerst hingehen sollte;
  • Datum und Uhrzeit, wenn es einen verabredeten Erledigungstermin gibt, die Arbeit per Datum geplant wird oder es eine Frist gibt;
  • einen den eigenen Prozeß abbildenden Status – die eingebauten Podio-Tasks haben nur zwei Status: „zu erledigen“ und „erledigt“, aber vielleicht benötigt man z.B. einen für die Abnahme des Arbeitsergebnisses vor „erledigt“;
  • mehr als eine Beziehung zu einem Stammdaten-Eintrag – die eingebauten Podio-Tasks hängen an einem Eintrag, das war's;
  • Zahleneingabe z.B. für geschätzten Zeitaufwand;
  • Buttons zum Anstoßen von Aktionen, beispielsweise Start und Ende einer Zeiterfassung
  • Berechnungsfelder, die an der Aufgabe selbst „geerbte“ Informationen aus verbundenen Stammdaten-Einträgen darstellen, z.B. Name und Telefonnummer des Mieters.

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.

Verschiedene Konzepte beim Verbinden mit Stammdaten

Separate Felder für jede Hierarchieebene

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!

Ein Feld für alle Hierarchieebenen

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.

Fokus durch gefilterte Ansichten

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.

Filter, Sortierung, Spaltenauswahl, Ansichtstyp-Auswahl

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:

Mein Kanban-Board

Bildschirmfoto Gebäudemanagement Kanban-Board

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

  • in einem „verantwortlich“-Feld den Podio-Kontakt der verantwortlichen Person einträgt;
  • nach „ich selbst“ filtert – ja, Podio weiß, wer ich bin, denn ich habe mich eingeloggt!

Meine Liste für unterwegs

Screenshot mobile App Einsatz-Liste Gebäudemanagement

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.

  • zusätzlich auf die Status „als nächstes“ und „in Arbeit“ einschränken;
  • zusätzlich nach einem Datumsfeld mit „Heute“ filtern.

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.

Unterschiedlich sortierte Listen

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.

Weitere Beiträge von „Facility-Management mit Low Code“

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!

Updates direkt in Ihr Postfach

Tragen Sie Ihre E-Mail ein und erhalten Sie wöchentlich unseren Newsletter. Kostenlos und jederzeit abbestellbar.
Ihre Daten sind sicher. Hier ist unsere Datenschutzerklärung.

Noch keine Kommentare vorhanden

Was denken Sie?

Beliebte Artikel

Drupal 7 Migration White Paper veröffentlicht

Drupal 7 Migration White Paper veröffentlicht

Wir haben heute unser erstes White Paper veröffentlicht. in diesem haben wir alle Informationen zusammengetragen, um den Wechsel von Drupal ...
Weiterlesen
No-Code- und Low-Code-Development mit Citrix Podio

No-Code- und Low-Code-Development mit Citrix Podio

Der von immer neuen „Buzz Words“ geplagte Entscheider hört, wenn es um Unternehmenssoftware geht, zunehmen davon, dass die Zukunft ...
Weiterlesen
Datenmissbrauch ist schlecht für die Marke: So schützen Sie sich davor

Datenmissbrauch ist schlecht für die Marke: So schützen Sie sich davor

Die Sicherheit der eigenen IT-Infrastruktur und Website wird immer wichtiger. Nicht nur, weil Ausfälle teuer sind, sondern auch, weil die ...
Weiterlesen